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
Partner Zones AWS Cloud
by AWS Developer Relations
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
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Seven Steps To Deploy Kedro Pipelines on Amazon EMR

Trending

  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Seven Steps To Deploy Kedro Pipelines on Amazon EMR
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Using Kanban for Scrum Backlog Grooming

Using Kanban for Scrum Backlog Grooming

Anders Abel user avatar by
Anders Abel
·
Mar. 29, 13 · Interview
Like (0)
Save
Tweet
Share
9.92K Views

Join the DZone community and get the full member experience.

Join For Free
Keeping track of the backlog in a Scrum project is a challenge. It quickly grows to hundreds of items that are in various state of readiness for inclusion in a sprint. In my current project, we’ve setup a Kanban board to help managing the backlog and make our backlog grooming sessions efficient.

I think that in many ways the product backlog and the product owner role are Scrum’s weak spot. Scrum brings order to the development process and sets clear demand on the specifications input into the development process. That helps to make visible what we developers have known all the time: It isn’t our fault that projects screw up, because we can’t do a good job on bad requirements. So with Scrum having helped to make the requirement problem visible to everyone it’s time to address the requirements handling.

In my current project, there are a number of distinctive steps that a product backlog item goes through.

  1. A new request from someone is noted as a product backlog item.
  2. The PO decides to trash it right away, or to go forward with more detailed analysis.
  3. The PO (or a BA helping the PO) makes an analysis.
  4. The product backlog items is presented to the developers in a backlog grooming meeting.
    • The developers have questions and send the item back for further detailing.
    • The developers approve the item and make an estimate of the entire product backlog item.
  5. Only items approved by the developers are eligible for inclusion in a sprint at the sprint planning meeting.

To keep track of this process we use a Kanban board.

The Kanban Board

Our Kanban board has four columns, which maps to the process outlined above.

  1. New
  2. Investigate
  3. Requirements Done
  4. Backlog (or Requirements Approved)

When an item is first added to the backlog it is put in the new column. The product owner decides if it’s even worth to put any effort into investigating the request at all. If it is, then it’s moved on to the investigate column. That is the “work in progress” column for the product owner and business analyst. When they think that they are done, they move it over to “Requirements Done”. Once that column contains 10-20 items (we don’t have a hard limit) it’s time for a backlog grooming meeting where the developers look at the product backlog item. If the developers think that the product backlog items is clear enough to be able to work with, they move it to the final “Backlog” state. The development team also gives a time estimate at this point (we use hours and not story points).

If the developers on the other hand think that there is something missing in the product backlog item description they send the item back to the Investigate state, together with a list of questions that need to be answered.

The Sprint Planning

When it’s time for the sprint planning meeting, only those items that are in the “Backlog” state are considered. We use JIRA and I’ve actually filtered the board we use for planning so that it won’t even show items that have not yet reached the backlog state.

At the sprint planning meeting very little time is spent discussing what the items really mean – that has already been done during the product backlog grooming sessions. The focus is instead of getting a list of prioritized items from the product owner to move into the sprint. At this time the product owner has the time estimates on a product backlog item level. With the cost known and the benefits for the business known (the PO should really know the benefit for the business) it is possible to make an informed decision on whether an item should be done now, deferred to a later sprint or perhaps isn’t worth doing at all.

Get the Backlog Process Under Control

With an efficient development team thanks to the scrum practices it’s more important than ever to make sure that a backlog is produced that give the developers the information they need to be efficient. Trying to manage the backlog without proper tooling support or without a clear idea of how to get all those items into a detailed enough state is hard. It is even impossible for all but the smallest project.

If we spend so much time to improve the development process I think it should be natural to also look at the process that leads up to the development phase. Unfortunately I think it’s quite rare to a have a well defined workflow for getting items into the backlog. In my experience that work is often done in an ad hoc manner, which I think is wrong.

I’ll continue with my Kanban board to make sure that the product backlog management doesn’t degrade to an ad hoc work flow. It is evident just after only a few months that a proper product backlog management process with good tool support helps.

Sprint (software development) scrum Kanban (development)

Published at DZone with permission of Anders Abel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
  • Never Use Credentials in a CI/CD Pipeline Again
  • 5 Key Concepts for MQTT Broker in Sparkplug Specification
  • Seven Steps To Deploy Kedro Pipelines on Amazon EMR

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

Let's be friends: