The Power of the Backlog

Achieve More Using Prioritization and Creativity

27 February 2014


The product backlog and the sprint backlog are powerful tools to drive an Agile project to meet its objectives. Though the primary purpose of the backlogs is to document the requirements and work items, practically speaking, much more could be achieved by creatively structuring them and prioritizing the items.

This article uncovers the power of backlogs.

Requirements and their prioritization

The product backlog primarily serves the purpose of documenting business requirements, addressing functional and nonfunctional aspects.
  • A functional requirement could read be, "As a valid user, I want to ensure that after I schedule a cash transfer the cash is actually transferred to the payee as per the schedule so that payee's commitments are not affected."
  • A nonfunctional requirement could read as, "As a valid user, I want online banking to be always available so that I can schedule a transfer during any time of the day."

Once the requirements are documented, the product owner (PO) prioritizes them using input from the business strategies and the product vision, along with those from the development team. Value to the business is one of the key considerations for prioritizing the requirements. The ScrumMaster facilitates sessions between the business (PO) and the team members to get the final list of prioritized requirements.

Keeping the product backlog updated on a continuous basis will help the team use it as the one-stop shop for all requirements, changes to requirements, and priority of requirements. A product backlog created and maintained with such discipline will serve as a priceless reference when a CIO organization makes decisions related to application rearchitecture, technology refresh, application rationalization, outsourcing maintenance/support to vendors, etc.

Specifications for the engineering activities

Once the requirements are clearly documented, the product backlog, along with the sprint backlog, could also be used to document specifications for engineering activities. The specifications could be documented in the form of child user stories at the necessary levels of granularity.

Subsequently when the sprint backlog is created, the specifications could be mapped to specific tasks for the team.

Supported by clear Definition of Done (DoD), each engineering specification would serve as vital guidance for the development team for further enhancements and for the support team for better servicing user tickets. Test cases are often derived from well-documented specifications.

Planning and work prioritization

Where is the list of items to be completed by each team member in an Agile project? The sprint backlog could serve as a work list for each team member. Depending on the tool used to create the sprint backlog, timely alerts on tasks could also be provided to team members. For keeping things up to date while the product backlog is groomed, the sprint backlog would also need to be groomed to prioritize work items using the outcome of every day's stand-up meeting.

By constantly reviewing the sprint backlog, the team gets logically organized work for each team member in sync with the user stories. Care must be taken not to allow changes to user stories while "grooming" the sprint backlog.

Risk management -- mitigation action planning

The sprint backlogs could help in the effective mitigation of risk. While planning for the sprint, the team discusses items such as requirement priority, effort required to complete the user stories, team bandwidth, and potential risks. When the risks are identified, the team also defines appropriate mitigation actions. The sprint backlog could be used to document the risks and specific mitigation action items.

By attaching a DoD to the mitigation actions, the risks could be closely monitored during the sprint and successfully mitigated. The daily stand-up would include the risk monitoring activities as well.

The grooming sessions would help identify newer risks and the team could document these and the mitigation actions in the sprint backlog for effective tracking and closing.

Communication and collaboration

Typically, in a distributed development environment, teams have different cultural and social backgrounds. There could also be teams that do not speak a common language. Clearly, the language barrier would limit collaboration and affect the productivity of the team. This could eventually reflect poorly on the quality of the deliverables.

The sprint backlog could play a major role in alleviating this situation. The ScrumMaster, with input from the team, could include the right activities at the necessary level of granularity for the tech teams. The team could be structured to position one person speaking the common language and the local language at each location. This person could enable all the team members to understand the specific tasks related to each product backlog item and help them pick the stories that they would be comfortable with. The key here is that the sprint backlog should be granular enough for the person to interpret the items to the team members.

Articulation of business benefits

The product backlog provides a platform to determine the business value for each user story. While prioritizing the requirements, the PO thinks through how it will benefit the business. The business value could be in actual dollar terms or a rating such as High, Medium, or Low.

After attaching the business benefits and prioritizing the requirements, the team clearly understands where they should focus and how their deliverables will impact the business.

The benefits defined in the product backlog provide visibility to the business leadership on the value that the Agile teams have been able to deliver through the sprints. Such business value attached to the features would immensely help vendor partners/service integrators bill the customer based on delivered value.

Enabling status updates to stakeholders

Work completion, burn-down charts, velocity, etc. -- all derive their basic input from the product backlog and the sprint backlog. The various charts and metrics provide the necessary status updates to the stakeholders sprint after sprint. As stated earlier, the key risks are also highlighted to the stakeholders based on inputs from the sprint backlog.

Especially with multiple Scrum teams working on a solution, the integrated and continuously updated product backlog helps the business and the IT leadership understand where the solution is in its development cycle. Architects get a view of how the solution architecture is evolving and they could take early action to refine or make improvements to the solution. Vendor partners understand how their apps and interfaces should be designed to meet the emerging solution.

Key attributes of a "good" product backlog

A product backlog would be:
  • Appropriately detailed
  • Estimated
  • Emergent
  • Prioritized
  • Traceable

The product backlog is an ordered list, which means that every item on the list is part of a whole, with no two items holding the same position. This means that every item in the backlog cannot be "Priority One." By applying this rule consistently, the product owner makes decisions about which group of stories would go into which release to production.

Conclusion

As delivery teams mature and the use of Scrum processes becomes effective, the product and sprint backlogs should provide more accurate and valuable information. The teams should be able to structure their backlogs and document the items accurately in order to use them to their best advantage and deliver value to business.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

David Lowe, CSP,CSM, 3/1/2014 7:34:31 AM
I have to say I'm a bit confused by some of what you say.

Do your an "well-written requirements" when you say "well-documented specifications"? You description sounds like full specifications should be provided.

Also, what do you mean when you say "the sprint backlog would also need to be groomed to prioritize work items using the outcome of every day's stand-up meeting"?
David Lowe, CSP,CSM, 3/1/2014 7:37:26 AM
Sorry, 2nd paragraph should have started "Do you mean well-written ...
Rob Langdon, CSM, 3/3/2014 7:41:06 AM
"Do you mean "well-written requirements" when you say "well-documented specifications"? You description sounds like full specifications should be provided."
Like David, I'd appreciate your clarification on this as it's a question I'm struggling with at present...
Ravishankar N, CSM, 3/5/2014 4:59:50 AM
David, 1) you are right - I meant well documented requirements that are clear to all the stakehoders.
2) The Sprint backlog will also be dynamic based on team discussions. If a task has to be done on priority to mitigate a risk that will have to brought to the top along with the dependant tasks.
Ravishankar N, CSM, 3/5/2014 5:01:10 AM
Rob, hope I have answered your question as well in my response to David.
David Lowe, CSP,CSM, 3/6/2014 3:42:03 AM
Although I accept that the priority of PBIs 'within' a sprint could be juggled during the sprint, I'm not sure that describing the sprint backlog as "dynamic" is that wise an idea; that may encourage people to think that items can be brought in/out on a whim.

There's potential for a misunderstanding (similar to that which happened re 'commitment').
Ravishankar N, CSM, 3/12/2014 5:03:35 AM
You are right! The Scrum Maaster should use his logic and reason before allosing changes to the Sprint Backlog.
David Lowe, CSP,CSM, 3/13/2014 3:15:09 AM
As long as it's clear that the sprint goal is the focus and that ONLY the development team can change items in the sprint backlog. Removing items is certainly encouraged (if they are no longer deemed necessary).

You must Login or Signup to comment.