Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
You'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
So let's create a backlog item. We'll start by writing up an idea of what we want in the application:
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
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
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
- 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
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.
Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.