"That went very well." Said in reference to today's sprint planning session, and an inferred commentary upon the previous planning session which was a tornado disaster zone of a trailer park.
Few people like to attend a disaster waiting to happen. But I've found that there are times when it's the best thing that can happen for a team. And while I don't cheer for the tornado, I don't mind its visit to the sprint planning meeting once in a while.
I'm typically heard explaining why the tornado hit our little trailer park... it's because we didn't do any (or enough) backlog refinement. And then people want to know what backlog refinement is - what should happen in these "meetings"?
If you search the old books and articles on Scrum you might not find this meeting mentioned. But that's just because refining the backlog was something that most teams understood needed to happen and did what needed to be done. Somewhere along the path, people started treating the Scrum process as a strict set of requirements defining the precise activities one should do, and ignored all the experience in the room. Hence the mistake and the poor planning activities that are common.
Add in a smart Backlog Refinement Activity each sprint and planning becomes easy.
A set of activities for the refinement meeting can be chosen from among these:
I'm typically heard explaining why the tornado hit our little trailer park... it's because we didn't do any (or enough) backlog refinement. And then people want to know what backlog refinement is - what should happen in these "meetings"?
If you search the old books and articles on Scrum you might not find this meeting mentioned. But that's just because refining the backlog was something that most teams understood needed to happen and did what needed to be done. Somewhere along the path, people started treating the Scrum process as a strict set of requirements defining the precise activities one should do, and ignored all the experience in the room. Hence the mistake and the poor planning activities that are common.
Add in a smart Backlog Refinement Activity each sprint and planning becomes easy.
A set of activities for the refinement meeting can be chosen from among these:
- prioritize the list - in "delivery" order (not by other criteria)
- size each story - if this takes too much time - break out into its own activity and learn to relative size stories quickly
- slice stories that are too big - if the team doesn't know "too big" when they see it... keep practicing this knowledge will come
- after slicing - reprioritize - e.g. constantly reprioritize (you're looking for story slices that can be deferred until much later - or never)
- within the slicing activity you are rewriting stories - so get good at telling stories and capturing the necessary details - learn to title stories AFTER writing them
- compare sliced stories to the original for size... learn about your estimating skills - practice estimating a lot, to get better at it
- write a list of the top acceptance criteria for each story (doesn't have to be an exhaustive list)
- define what is NOT included in the story - this list may be more important than what is inferred by the story
- discuss the story dependencies - and how to remove or "mock-out" the dependencies - capture these dependencies in other stories
- sketch a GUI for the story if needed - if working from wireframe GUI it's useful to redline the GUI controls that are not included in this story
- resolve to NOT include any read-only data in the DB
- note the DB mutations required and treat the DB as an artifact under source control
- draw a picture for this story - it is worth 1000 words!
With a bit of practice, I bet you could add to this list... it is not complete - but just Good Enough... good enough to get you to the Sprint Planning session with a well-groomed backlog.
See Also:
Scrum Training Series - Backlog Refinement - video by Michael James
Comments