Whether your following the SCRUM process or not, at some point you've been asked to "estimate" your work. Not surprisingly, the answer to this question often comes in the form of days, weeks, or months. If your providing a Rough Order of Magnitude (ROM) (a.k.a. ball park estimate) for some proposal this may be fine, although this kind of estimation can get you in trouble if you don't add that all-important padding. At this point, your probably saying... Duhhh!... and you surely recognize why. We add padding because we've not taken the time to think about the details.
Unfortunately, it's all too easy to follow this same pattern in Sprint Planning. I can't count the number of times I've witnessed Backlog estimation with the same cavalier days/week estimation approach. To be fair, I've been guilty of it myself and usually pay the price of over-committing myself because I skipping the details. According to SCRUM process tenets, the second half of the Sprint Planning session is dedicated to breaking down "how" we'll deliver the requirements identified in each Product Backlog Item. This is the time for us to think about the detailed tasks that must be accomplished as part of any piece of work. Look around, and you'll find no shortage of guidance on how to structure these but lets see what Ken Schwaber has to say.
While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day.
- Scrum.org (http://www.scrum.org/scrumguides/)
Notice there is no specific number mentioned, although it's implied we should break tasks into sizes no larger than one productive day (whatever that is). This is really clever, because; if achieved; team members can easily assess real progress from one day to the next and be able to both report and observe this progress in the Daily Scrum meetings. If we combine the desire to avoid over-committal with making progress more observable for the team, this seems like a no brainer... Then why do we keep skipping the all-to-critical break-down step? Assuming it's not plain old laziness, maybe we just need some ideas on how we can break down tasking. For me, I often use my definition of "Done" to start guiding my detailed task list.
- Author Code - Try separating your target layers into separate tasks (Ex. Domain Repository, Dal, etc.). This isn't meant to represent a list of classes but it can represent layers of discreet behaviors/functionality. If your developing visual interfaces this could reflect components, user controls, or other visualizations
- Author Tests - As a compliment to authoring the code, create separate tasks for testing each developed layer or component. The previous tasks allow you to report on implementation of required functionality while these tasks allow you to report on the confidence with respect to completeness, reliability, etc...
- Integration - These tasks identify work often required for larger products and may represent dependencies you have on other resources such as graphic arts, localization teams, etc. Additionally, you may also want to set aside tasks to integrate new products and/or components into your build process, source control, and/or CI tool-sets
- Reviews - This reflects interactions you inevitably need to have with other people, and can serve as a nice reminder that you need to coordinate/review material you've authored/updated. This could include things like peer reviews with other developers, component introduction with the test team, etc...
- Deployment - Set aside tasks specifically targeted to implement/update those things you need to deploy your product. This may include installers, configuration profiles, monitoring resources, data stores, etc...
- Documentation - This reflects tasks related to documenting what you are going to do or have already done. This could range from release notes, code documentation, test cases, user documentation, etc...
- Demo/Review - Don't forget to set aside a task to prepare product scenarios for the Sprint Review/Demo
This isn't meant to be a complete list and I'm sure you can think of additional items. If you think about it, this really isn't hard and making a quick bullet list of items such as I've done above doesn't take much time. Conducting exercises like this may help you realize that your shoot-from-the-hip estimation may not be enough to produce a "complete" product. As an added bonus, this kind of detail in your estimate can really help facilitate discussions with those that complain... "What do you mean that takes two weeks?". As with most things, the devil is in the details, so don't just assume you'll remember them, break them down...
Tags: processes