Breaking Down the Scrum Product Backlog
Join the DZone community and get the full member experience.
Join For FreeYou'll hear me mention this a lot because I don't think it's given enough credence elsewhere:
The Product Backlog is the backbone of implementing Scrum
successfully. Properly sizing the backlog items, creating good
estimates, prioritization, and creating a definition of done all play
into the product backlog and having all of these will make your life
easier in a number of different ways.
So what goes into a successful product backlog? It's going to
be the work that directly affects the final product and only the work
that directly affects the product backlog. This means new features, bug
fixes, slight tweaks to the interface and technical debt. All of these
things are (usually) treated generically as simply "Product Backlog
Items" (they're also sometimes called User Stories but that's another
post).
So let's create a backlog item. We'll start by writing up an idea of what we want in the application:
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.
Now at this point, we need to know if this backlog item is
important. This is where your Product Owner will come into play, he'll
decide if this should be at the top of the backlog or near the bottom or
somewhere in-between. In short we need to know the priority of these
backlog items.
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.
Now you need an estimate and this is probably the most
important part of the backlog. Good estimates allow you to commit to
just the work that you can get done in a sprint and very often
over-committing is a great way to fail your first few sprints. While I
can't guarantee that you'll do this right when you first start
estimating I can say that padding your estimates is most definitely
something you'll want to avoid. Here's a couple things to keep in mind
when estimating:
- 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.
So that's really all we need in a product backlog item. Build
your backlog with that info and you've got a great start to your first
sprint. Next on the docket: Sizing your backlog items and estimating.
Sprint (software development)
scrum
Published at DZone with permission of Sean Mchugh, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Competing Consumers With Spring Boot and Hazelcast
-
Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
-
Microservices With Apache Camel and Quarkus
-
RBAC With API Gateway and Open Policy Agent (OPA)
Comments