This meeting occurs before the start of an iteration. The team meets with the TeamLead and product developer to see which stories are ready to be accepted into the next iteration. The team might estimate the stories, but they will accept or reject the work they think that they can complete in the upcoming iteration.
- The team doesn’t understand how to complete the stories they’re trying to implement
- Developers and testers frequently argue about when something is finished or what it should be
- Product developers are frustrated by what the team is building
- The team expends considerable time and resources trying to learn what a story is supposed to be, or what the users want
The primary benefit of this practice is an efficient use of the team’s time. When a team attempts to combine the StoryRefinementMeeting, the planning meeting, and iteration kick off meeting, then a subset of the team debates stories and meaning of stories, terms, and intent, while the rest of the team is bored and checks out. Symptoms of “checked out” teammates include laptop, tablet, and phone usage, internet surfing, game playing, doodling, yawning, and side conversations.
The more powerful, and less recognized benefit, is that by sharing the stories with the teams earlier, you allow the team to think about these issues and remember (or discover) information that they’re not going to recall if you put them on the spot in a team meeting. Developers have long recognized that our brains have the ability to do background processing. Our brains solve problems when we present them with information and then do something else (see Pragmatic Thinking & Learning for details). This mode of work harnesses those background processes and allows the teams to understand the work they’re beginning much more completely.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- The product developer collects a set of stories for the team to work with in the next iteration. Collect 150% of what you think they can complete.
- Review each story with at least one developer and one tester before the meeting. Use this time to learn more about the story and ensure it contains sufficient detail
- The product developer assembles the team and presents candidate stories
- The team discusses each story and decides if they understand the story well enough to work on it
- The team (often) sizes the story using points or t-shirt sizes (relative sizing)
- The team decides how many of the stories they can complete in the upcoming iteration
- At the end of the iteration, the product developer attends the demo, and the team shows their work
- The product developer decides if the story is what they expected… they either accept or reject each story. Significant differences of opinion mean the stories need more initial discussion.
- See if everyone involved had the same level of expectation about the stories
- See if the team is able to complete their commitments
What Does it Look like?
Story refinement is the product developer having a series of daily meetings (some scheduled… some ad hoc) with developers, testers, and customers. In these meetings, story details are debated, discussed, sometimes argued, but understood. The team decides what the report should look like here instead of waiting for the demo to discuss the number of fields. Or the preferences pane, or the work flow, or …?
A planning meeting is the team coming together to review stories again, this time in priority order, and to estimate relative story size, before deciding how much work they’ll accept into the iteration.
- The product developer tells the team what stories they’ll work
- The team is told who will work on which story
- The team consistently accepts far more work than they can complete
- The product developer brings incomplete stories that aren’t ready for the team to discuss
- No one but the product developer has seen the stories at the time the stories are unveiled at the planning meeting
- As a team, work towards completing your commitments, not becoming “Yes man” team that over commits, but can’t deliver
- Work on acceptance criteria that the product developer, developers, and testers can all understand and agree to use
- Do enough preparation that the planning meeting is fast
Exercises to Get Better
- Try to completely prepare one story every day (during the iteration before the planning meeting)
- Work on a story alone, then with only a developer, then only with a tester, then both. What is each perspective missing?
- Do a root cause analysis on any story rejected by your team. What didn’t they understand? How can you make new stories more clear? Different language? More detail? Pictures? Sketches?
- Do a root cause analysis on any story rejected by the product developer. Did the team not understand the level of work required? Was the story written poorly? What went wrong? How can we avoid this in the future
How to Teach This Practice
The best way to learn this is to watch others doing it, then do it yourself. But that’s true of most practices, isn’t it?
Try pairing with another product developer who’s already doing this. Shadow them for an entire iteration and watch how they work. Help them work on their stories.
Then try it yourself. Follow Jerry Seinfeld’s idea of not “breaking the chain”, or the writer’s habit called “Daily pages”. Anything you want to do well, you must at least touch at least once every day. So every day, as a product developer, touch at least one story. Read it. Review it. Try to add some detail. Some days you might only spend five minutes on a single story, but other days you’ll find yourself pulled into discussions that last half a day.
Every day that passes, you should make progress with at least one story. That ensures you’ll have a solid backlog ready for the team in the planning meeting.
Many larger planning meetings take all day. Some are multiple days. This is bad. Try to schedule your planning meeting for no more than half a day when you start, but know that with proper groundwork done ahead of time, you can wrap this meeting up in an hour.
How To Fail Spectacularly
- A product developer telling the team which stories, and how many, they’ll accept into an iteration
- Emailing the team with incomplete stories and asking them to fill in the details on all of them
- Emailing the team ahead of time and asking them to size stories via email
- A team that consistently pulls in more work than they complete
- Teams that realize their management is measuring “points” as a metric, so they artificially inflate their estimates in order to look more efficient
- The team is seeing stories for the first time in the planning meeting
(Iteration Demo) Next→