At the end of every sprint review, we have our sprint planning meeting... This is our most painful meeting. We've done a lot to mitigate the suffering and the pain has lessened in return. However, our process, like any, is not without flaws and some planning sessions just plain suck.
During sprint planning we review the user stories in our backlog. For our enterprise projects, Salim, our SCRUM master, keeps track of the stories and priorities and the rest of the developers usually know whats going on too. For the new product development our client proxy, Ilio, manages the backlog, which is always well thought out and organized.
Before the review, the developer's knowledge of the stories is anywhere from nothing to very familiar. The more unfamiliar we are with the stories, the more painful our meeting.
Makes sense, because unfamiliarity and uncertainty go very well together, and uncertainty, while unavoidable, makes for long conversations and design talk. Too many unknowns during one sprint review makes us desperate to end the meeting.
The meeting is suppose to go like this:
1. Salim reads a story card
2. On the count of 3 we hold up an estimation card (very easy, easy, medium, hard, very hard and unknown)
3. Salim writes down the estimation
4. repeat
This process repeats until we've estimated more than an iteration of work.
Seems pretty simple, right?
Except, it only happens that smoothly when:
1. The story and solutions are well known
2. Everyone is focused
Sometimes the process is more like this:
1. Salim reads the story card
2. Ilio is asked to explain what it means
3. Ilio explains the story
4. Someone disagrees with Ilio about some behavior on the card
5. Ilio explains the logic again (he's so calm its amazing) and if necessary goes to Bob, our user interaction guru
6. Salim asks if people are ready to estimate
7. Someone answers, "what story are we doing?"
8. The card is re-read
9. On the count of 3 we hold up an estimation card
10. There are only 2 estimations that match, the others range from easy to question
11. The highest estimation explains their reasoning
12. The lowest estimation explains theirs (unless they changed their minds)
13. Salim asks if we want to re-estimate
14. On the count of 3 we hold up an estimation card
15. Kris or Luke make a final decision if we don't agree
16. Salim writes down the estimation
17. repeat
That took a lot longer to read, no? Believe me it makes the meeting take a lot longer too!
Does this make you think we're disfunctional? I think we'd be disfuctional if it always went perfectly... That may sound odd, but its conversations like these that bring interesting design discussions, find issues we missed, discuss user interactions we don't like, etc. These are important conversations to have.
When planning gets filled with unknown stories, we'll have 15 minute meetings each day to discuss stories for the next sprint. This helps, but is difficult too, because its another meeting to fit in during non-war room hours and there is very little time as it is...
I think we all decided that we'd rather have one long day of meetings (which we're having anyway) and a slightly more painful sprint planning than think about sprint planning every day of the week.
At the end of it all, we just want to code :)
Subscribe to:
Post Comments (Atom)
2 comments:
I'm trying to optimize our process here and posts like this are being extremely useful. But I have a question
You mentioned that estimation is based on the explanation. Sometimes you need more details, hopefully enough to estimate.
On XP that's hardly enough, and there's a lightweight exploration phase, when programmers try ways to tackle stories.
Don't you guys use something like that? Or don't you miss an approach similar to that?
Thanks
When a solution is unknown, we'll spike it one sprint and do the story in the next.
Kris, another developer, made a good point in response to this post, in that we only do the spike when its really unknown; we should do this more often to avoid too much design discussion during planning.
In general, we try to keep our stories small enough so knowledge of the application plus the behavior of the story are enough to estimate; this only seems to work about about 1/2 the time though :)
Post a Comment