Don't lose control of your backlog

Have you come across a Technical Story Syndrome yet?

My product team is new to Agile, and in the early going developers fell in love with the formal user story definition. So much that everything they embarked on had to be first defined in this format. Before long my backlog filled up with stories literally like the one below:

  "As an XYZ developer, I want the benefit of a standardized API for storing (caching) items in the DC, as well as transferring (syncing) required items between the DA & DC, so we can improve development time by reducing the number of specialized APIs required."

For a typical Product Owner with background in Product Management this simply would not make sense, whether (s)he will care to admit it or not. An even better test, is showing this story to your customers. See if this interests them. Would they pay even a dollar for this feature? If not that's a sure sign we are dealing with the so-called technical story.

Developers will often insist that these technical stories help to make the product better. The problem with these stories however is that they cannot be ranked by the Product Owner in relation to other stories on the backlog, and if they cannot be ranked they cannot be ever worked on.

One way to deal with this is recognize the need for some proportion of team's capacity to be allocated to technical debt and simply include these technical stories there. In the beginning of the project this may involve some technical stories for building the plumbing, or the foundation of the product, later on the focus may shift to refactoring, performance optimization and defect resolution.

In my case I've created one technical debt story for each sprint, moved the technical stories underneath it, asked the team to budget for up to half of the available sprint capacity, and delegated to the team the decision on what needs to be tackled as part of this story (plumbing, refactoring, optimization, defects) and what has to wait till future sprint. Of course this is just a general guidance.

Once I placed a technical debt story at the top of the list, I was able to easily navigate my backlog and rank all the user-facing stories. Back in control I am!

In pursuit of the user story purity

As Product Managers we are accustomed to answering calls for better requirements, or better-written user stories as they are known in the world of Agile software development. It’s hard to argue with the logic behind this. Scrum teams can more efficiently groom their backlogs, decompose and size user stories and ultimately come up with better fitting winning solutions that keep our customers happy and revenue flowing. 

Let’s take a look at one approach meant to raise the bar with this. A scrum team was instructed to re-visit stories on its backlog using the following WHO, WHAT, WHY and HOW framework.

·      “WHO” … this speaks about the importance of defining the end user for the requested capability.

·      “WHAT” … the approach argues it’s important to define WHAT in terms that all scrum team members understand.

·      “WHY” … if you don’t frame the WHAT in a WHY, different scrum team members will each interpret a different reason, which will lead to very different solution approaches… “As a car operator I want a cup holder in my car so that I can store my loose change in it for tolls” is different than “I want a cup holder in my car so that I can drink my beer while driving”.

·      “HOW” … should simply stay out of user story definition, i.e. left to the team.

I have to say some of the discussions around user story descriptions were quite enlightening as they helped everyone on the team better understand the need and the scope of what’s requested. On the flip side, I've also encountered what seemed like recursive looping, where the scrum team having quickly agreed on WHO, endlessly circled between WHAT and WHY in the search of ultimate answer.

Take for example this wild goose chase:

• As a middle-aged daily commute driver I want a cup holder in my car so that I keep spare change there to pay for my tolls.
• As a middle-aged daily commute driver I want easily accessible place to store change in my car so that I don't scramble at the tollbooth.
• As a middle-aged daily commute driver I want a convenient, stress-free way to pay for my tolls so that I can enjoy my ride
• As a middle-aged daily commute driver I want to enjoy my ride because the life is short

… You can see where this can lead J 

At the end of the day PO defines the requirement in the form of Agile user story, based on his/her knowledge of the market and application domain. Time boxing these discussions is all it takes to ensure your team spends just enough time to understand well enough what needs to be done to be successful.