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">
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 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:
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 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.