Here's a scenario many of you are probably familiar with. You're at the end of, say, Sprint #7. The top-priority user story for this sprint is getting your login process down to five seconds. The sprint, the day, and the work week are about to end. You're waiting for the results of your automation sanity tests. Your QA team lead walks up to you, smiles, and says, "4.8 seconds." "Yesssssssss! Cross it off the backlog, and weekend, here I come!" You've got one foot out the door already.
Fast forward to exactly two weeks later, end of Sprint #8, same place, same time, and the same QA team lead walks in with a very different facial expression. "6.5 seconds." You now have to revive that "performance tuning" user story, fit it into the next sprint, rework priorities, coordinate developers, and shift things around. By now, you're thinking it's going to be a late night.
If you're in an agile organization, you're likely to have experienced this from one angle or another. Whether you're the agile product owner prioritizing features or a developer who has to shift focus and tweak performance for the umpteenth time, unplanned user stories can throw a wrench into the works. Some user stories keep coming back, and this creates problems in the regular backlog.
But the best way to deal with these problems is simply to embrace them.
Let me introduce you to spiral backlogs
A spiral backlog is one that manages spiral user stories. These are user stories that are expected to keep coming back. In the example above, a login process that took 4.8 seconds in Sprint #7 stretched to over six seconds after several actions were added to the login during Sprint #8.
Here's another example: if you have a user story whose definition of "done" is 90 percent code coverage in your automation tests, then that user story will keep coming back whenever new code is added to your codebase.
To formalize this, we can define a spiral user story as having the following attributes:
A measurable goal (login should take 4.8 seconds)
A current state (currently it takes 6.5 seconds)
The goal is measured frequently throughout the development lifecycle (code coverage is measured at every sprint)
The current state of the goal is likely to change over time, or it's planned to span many sprints because it's difficult to achieve
Here's where things get interesting
A spiral user story also has weight and a rank. The weight is a measure of the importance of the user story, and the rank is an overall priority within the spiral backlog that is calculated as a function of the other parameters. How you define the function is up to you, as long as it considers your goal, the current state, and the weight.
Let's take our performance user story as a concrete example and define that:
rank = (current state - goal) * weight
So if the login currently takes six seconds, our goal is four seconds, and the weight of this user story is two, then:
rank = (6 - 4) * 2 = 4
Now, it might not make immediate sense to compare the rank of a goal measured in time (performance) to the rank of a goal measured in percentage points (code coverage), but this can be overcome by either managing separate spiral backlogs for different types of user stories or normalizing your ranks to create comparable values. Note that the weight of a user story can be changed to reflect real business priorities. If something in your business environment has suddenly changed to make a user story more important, you can simply increase its weight. Its ranking will update automatically to give it higher priority in the next sprint.
Are two backlogs better than one?
Well, that depends on who's asking. If you're part of the development team, managing two backlogs would generate confusion, create overhead, and complicate the measurement of your team's KPIs. That's not what spiral backlogs are about. But for the product owner, the spiral backlog is a useful tool to provide perspective on and monitor recurring user stories. The way to make them work together is for the development team to reserve one user story at the beginning of each sprint as a placeholder. The product owner can then analyze the spiral backlog, select the highest-ranking spiral user stories, and insert them as items into that reserved user story at the beginning of each sprint.
In other words, every sprint (as deemed necessary by the product owner) contains a user story taken from the spiral backlog. In this way, the spiral backlog is transparent to the development team. They continue to manage a single backlog without having anything extraneous interfere with their agile KPIs.
"WIIFM?" you ask
Well, plenty is in it for you.
Previously, when a user story came back to bite you, you dealt with it by copy/pasting it into a new user story for the next sprint. Or you created a defect for it to keep it open until reaching the goal. By contrast, spiral backlogs offer a much more methodical way to deal with these user stories, with several benefits:
Spiral user stories are maintained in a separate backlog that follows the application development lifecycle throughout all the releases, without interfering with the regular backlog.
The spiral backlog lets you track spiral user stories across many sprints without having to resort to artificially manipulating the user stories.
Quantifiable metrics, such as rank, let you track progress objectively from one sprint to another and across application releases. You can aggregate metrics of the same type to get an overall picture of maturity and quality for that type of user story. For example, by summing up the rank of all performance-related user stories, you can create a metric that defines overall application performance and track that over time.
Spiral user stories are prioritized automatically based on current state values for each sprint, but you can also control the priorities of spiral user stories by changing their weight to match dynamic business requirements.
Take out the guesswork
Spiral backlogs help you manage priorities for user stories that must be addressed on an ongoing basis, such as those related to performance, code coverage, and more. With a bit of experience, you can aggregate metrics for these backlogs to quickly give you the big picture of your application's progress and quality and let you define quantifiable metrics for release.
By doing so, spiral backlogs take a lot of guesswork out of deciding if your application is ready for consumption or not. You define the goals, and the spiral backlog automatically shows you if you're getting there or not.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
