Please rotate your device.

Our website uses cookies to ensure you get the best experience while you’re here.


Avoiding Backlog Blunders

By: Joe Combs

Two young entrepreneurs are brainstorming ideas on sticky notes on the glass wall

Backlog Blunders

For a successful agile team, a proper backlog is as important to success as air is to breathe. Neglect the backlog and allow disorder and non-precedence to creep in.  The result?  Teams who thrash – trying desperately to determine what to work on, suffering from bad habits once extinguished, and losing the the agile culture and mindset you’ve worked so hard to foster begins to falter.   Teams who are led astray from their backlog are not uncommon, but there are a few categories of mistakes and mis-steps that seem to repeat themselves most frequently.  In today’s blog we’ll review these common challenges and discuss best practices to overcome them.

Format Matters

Story format is probably the greatest area of opportunity for agile teams.  When you were first introduced to agile you probably saw the familiar story card with its “As a<X> I want to <Y> so that <Z>” statements.

Although a good practice, using this story format alone is not a safeguard against untestable or conflicting acceptance criteria.  You may wonder if there are mockups, or tricks of the trade such as swim lane diagrams, to help define what needs to be done?  How much detail is too much or too little?  It’s definitely a tight rope walk.

The best stories meet the INVEST criteria, they are:

  • Independent – free from inter-dependencies as much as possible so they can be worked in any order
  • Negotiable – focus on business requirements, leaving the team leeway to figure out the how
  • Valuable – worth something, clear enough to prioritize
  • Estimable – clear enough for the team to confidently estimate
  • Small – only a portion of a sprint is required to complete the story.  large stories bring risk of carryover and often include too many unknowns for the team to be able to estimate
  • Testable – acceptance criteria are free from ambiguity so specific, actionable tests can be created

Questionable Estimates

Who estimates the stories in your backlog?  The most accurate estimates come from the people executing the work, yet teams continue to delegate estimates to lead developers, architecture councils and other similar groups.  This is a dangerous step toward a waterfall mindset, where we have specialized roles and a sequential, non-iterative flow of work.  The farther the estimators are from the work to be done, the more likely we are to feel the need to pad the estimates to account for unknowns.

Tools like planning poker can help a new team get comfortable with the idea of gaining consensus on an estimate.  Over time, a mature team builds a level of simpatico that allows them to arrive ata consensus more quickly, so don’t be lulled into carving out part of the team as “professional estimators”.

Perplexing Priority

When my kids were younger they loved the movie, “The Incredibles.”  About midway through the movie, the villain reveals his plan to create gadgets that give everyone super powers, saying “When everyone is super, then no one will be.”  Is every story and every feature prioritized as critical, minimum marketable functionality or whatever your highest priority is?  How do you know where to draw the release line if this is the case?  If everything is your highest priority –  then nothing is!

Something’s Missing

Sometimes what isn’t in the backlog is as important as what is.  Technical debt, backlog mitigation and necessary architectural improvements all need to be visible.  This can present a challenge for prioritization as a lack of clear business value can push these items down the list.  There are a variety of tactics to cope with this common blunder, but the most effective teams avoid split backlogs and instead make extra effort to articulate the value of this work. They then guard some of their capacity to complete this work in a timely manner.

A Certain Lack of Refinement

Some teams mistake agility for just-in-time requirements.  Others set the priority of the backlog and then never revisit to re-prioritize despite feedback and lessons learned along the way.  At its best, backlog grooming or refinement is an ongoing process.  It helps to add an event or two to your sprint cadence in order to carefully consider the backlog and look at the road ahead.  This intentionality can pay huge dividends, giving the product owner a steady touchpoint to collaborate with the team and maintain a healthy backlog.

The Path Forward

Properly refined and groomed, the backlog provides a clear picture of the work to be done and the most important aspects of that work, so the team can focus their energy and operate at a steady, predictable rhythm.  Teams that are thriving with agile have mastered the art of creating and maintaining a solid backlog.  They INVEST effort in well formatted stories with clear and concise acceptance criteria.  They show intellectual honesty when it comes to estimates and priorities and they work to ensure the backlog paints a holistic picture of the work to be done.  The good news is that by getting intentional about your backlog you can sidestep these blunders to wow your stakeholders and elevate your team’s agile game.

Joe Combs


More posts from this author