Breaking Down the Scrum Product Backlog
Join the DZone community and get the full member experience.Join For Free
It doesn't need really need to be much at this point, really just a name to stimulate conversation about what it will look like when it's implemented.
Ideally at this point the product owner would also give us a detailed description of what this will look like when it's implemented but they may need some guidance or feedback from the development team to know what to define.
- If a work item seems too big to estimate accurately, break it up into smaller work items. You can attack it piecemeal from there and you'll also get the added bonus of implementing a backlog item over the course of multiple sprints if need be.
- Each backlog should be as independent from the others as possible. Try to avoid creating dependent backlog items as this fuzzies up the straightforward approach we're going for and adds a whole other layer of complexity that doesn't need to be there. If you absolutely need to, make the sequencing of your work items part of the priority system. The fewer moving parts you have the better.
- Your estimates have nothing to do with actual time. This is important, your team may estimate a sprint's worth of backlog items at 1000 hours and then finish early (or not finish, that's another article). That's okay, simply plan more work for the next sprint. What's more, a 3 day feature may take a new developer 5 days to finish or an experienced developer 2 days, that's okay too. Accurately estimating the backlog has more to do with how much work can fit into a sprint than it does making certain that our estimates are accurate. (Remind me to write about estimating in story points soon)
- Don't estimate low priority backlog items. Developer time is precious and while we might get to the bottom of the backlog someday for right now we're strictly concerned the work that might make it into the next sprint. Start estimating from the top and make your way down until you're comfortable that you have enough to plan the next sprint. Descriptions may change for lower priority items or new higher priority items may be added before the next sprint, don't worry about it for right now.
Published at DZone with permission of Sean Mchugh, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.