My thoughts today is about how the team picks stories at the sprint planning meeting.
One point of the sprint planning is for the team to be allowed to pick the amount of work they feel they can cope with, and commit to, for the coming sprint. As a preparation for the sprint planning meeting, the product owner goes over the backlog and revises the story prioritizations based on most recent feedback/input from sprint reviews etc (whatever affects the priorities).
Our approach up until recently was to let the product owner present and make available (e.g. on a whiteboard) the X topmost stories in the backlog. Those stories would be considered "up for grabs"on the sprint planning, but without relative priority. The team could freely pick any of them, in any order. It sounded so good on paper; the team has complete freedom over which stories they pick, yet the product owner has a say about it by means of him prioritizing the backlog prior to the sprint planning meeting.
The pitfall with this is that since the team picks any stories from the top of the product backlog, the stories enter the sprint backlog without priority; or at least the priority has less of a meaning now. And it is therefore tempting to just regard the set of stories in the sprint backlog as one big unordered set of stories - all which must be completed. And as a consequence you lose one of the most valuable concepts of Scrum & Agile: focus on the most important thing first. Plus, it leads to people in the team isolating themselves with one story each, which means the cooperation effect is lost.
Don't do what we did!
So how should you do it? Well, the product owner should prioritize the stories in the backlog, and they should be ready-ready (see previous blog post). On the sprint planning meeting these stories are put in a list and the team can not just pick any of them. Instead, what the team does is to draw a line somewhere. That's it. This drawing of The Line represents their committment. Everything on one side of the line is what they commit to delivering, and the rest is left for consequtive sprints; or whatever the product owner choose to do with them. In our case, we should have the stories printed out on index card papers, and put on a whiteboard from left to right in descending priority order. The team then draws a line using a whiteboard marker. Simple enough! :-)
The Value of Recreational Programming - If you’re a manager, an agile coach, team lead or scrum master with no programming background, that might not be a problem. It may even turn out to be some...
4 weeks ago