Estimate like you mean it
- Poker Check from Photos
Scrum says that planning poker should be short, snappy, time boxed and fairly rough. The more ambiguous the stories, the higher the number on the Fibonacci scale. This is great, it allows you to discuss the story at some length, make sure you’re all on the same page and then throw up a number.
What if your team doesn’t understand every aspect of the project? If you’re new to scrum, or you’ve got silo’d ‘specialists’ for different segments of your product or company (and, honestly, who hasn’t?), or you’ve got a new team member, perhaps a new hire, or someone from another team altogether, then planning poker might not be the most productive hour of your week. You might need to spend time during planning discussing what the story is, how the section of the product or application works and why. That’s going to eat into your timebox for discussing the actual story. So, how do you get round the fact your team isn’t all fully aware of the entire application, or even, in some cases, the part of the application your team is assigned to?
You could just go for it anyway, you might get lucky and everyone estimates the same anyway, your velocity may change, perhaps, but it’d stabalise in the end. Or you could run some workshops to get the new team members or those unfamiliar up to speed with the product, but that eats into your sprint time.
Or, you could send out the story ahead of time and let the team members spend some time pondering it before poker. Email or print and drop on each persons desk a list of the stories (which should be well defined and adhere to the I.N.V.E.S.T acronym) and let the team spend some time getting a feel for them. Those that are most familiar with the project can scan through to see if there’s anything out of the ordinary and those less familiar can spend a little time asking other members of the team, or even getting acquainted with the code. Up close and personal like. That way, when you come to planning, your timeboxes could, if you wanted, be that much shorter and your estimating should be more accurate, making the entire process a bit more solid. As more accurate estimates lead to confidence in committing to stories, lead to delivering what was committed to, leads to sticking to a release plan, leads to the team being full of WINN!Of course, this does all assume that your stories are well defined…
Should you bother with a product backlog?
I recently started a conversation on the agile development group over at Yahoo Groups. My initial question was, should I ditch the product backlog? We tend to do a lot of just-in-time development, the requirements come in, sometimes mere hours before our sprint planning and as such, these stories are only on the product backlog for a very short period of time, if at all. Often they’ll just come in via email from the Technical Director and they get added to the sprint. The backlog, then, becomes ever growing and it seems that some of the stories on there will never be looked at again, let alone completed. It’s the fable of the ever-growing backlog.
So, do we even need it? Jack Milunksy of Agile Buddy fame said, if you’re not using it, then in pure lean fashion, ditch it and stick with the just in time. Others have said, if you’re not using a product backlog, how will you define a release strategy or be able to roadmap the product? Which is a good point. The answer then is that it depends. Why is this always the answer with anything scrum? 
If you’re using the product backlog as a place to store and prioritise stories, use as a release manager or roadmapper, then you should keep at it. If you’re using the product backlog as somewhere to store half-formed ideas of possible features of additions to your product, then maybe you should use a backlog. If you get your priorities minutes before the sprint starts, hastily written on the back of a beer mat, then maybe not. Or, maybe just use it to store high priority stories that are definitely going to be worked on but not yet.Above and beyond all this though, is grooming. If you don’t groom your product backlog, then you’re in a whole world of pain. Epics, which are at the bottom will suddenly become top priority and, without grooming, will still be Epics. Your team may even throw things at you, I wouldn’t be surprised. So groom the backlog regularly, get the team involved and make sure you’re breaking stuff down!
Update: Jack Milunksy over at the Agile Buddy blog even blogged about this: http://blog.agilebuddy.com/2009/11/do-you-even-need-a-product-backlog.html
leave a comment