DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Breaking Down the Scrum Product Backlog

Breaking Down the Scrum Product Backlog

Sean Mchugh user avatar by
Sean Mchugh
·
Jun. 11, 11 · News
Like (0)
Save
Tweet
Share
3.30K Views

Join the DZone community and get the full member experience.

Join For Free
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 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.

Popular on DZone

  • GPT-3 Playground: The AI That Can Write for You
  • RabbitMQ vs. Memphis.dev
  • Kubernetes vs Docker: Differences Explained
  • The New DevOps Performance Clusters

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: