Manage Learn to apply best practices and optimize your operations.

Agile development: Quality assurance, consistency in testing

Learn how to use Focus Stories to organize and manage dense software development backlogs. In doing this, your Agile software team will have less hassle completing iterations and prioritizing important deadlines.

In the third installment of this series, we'll discuss how the Focus Story aids in planning and developing test, development, and release approaches. Learn simple ways to use existing information for filtering out what is immediately important and how to maintain consistency across a group of teams.

Backlog growth
Let's start with a persistent problem. Product backlogs become unmanageable as Agile goes large. The product owner is quickly overwhelmed as the backlog grows from 20 to 40 to 400 stories and continues to increase in an exponential manner as teams decompose, recombine, complete, split and create stories for their respective iterations. Once in development, bugs and enhancements add to the mix. Over a product's entire life cycle I have seen product backlogs grow into the thousands in a couple of years. A Focus Story acts as both a guide and a filter to keep the product backlog items aligned and to assist the creators in building the items.

Related content
Scaling Agile development: Get your Focus Story together
Learn to adapt to changing initiatives in an agile software project this may require altering test driven and acceptance test driven development practices are key to success.

Focus stories, business mission, goals, intents and the backlog
Software development roles evolve as product owner focus changes. Agile groups may need to adjust test strategy, roadmaps and iterations to ensure top-notch QA, says an expert.

Extending the value of the backlog
The growth of the backlog requires the team to regularly groom new backlog submissions, allowing for a smart product owner to use the Focus Story to combine several grooming tasks.

  • Filter – in / out- The first task is to decide if the story fits into the focus of the program at all.
  • Impact value – MoSoCoW the second task a Focus Story makes easy is to decide if the story is a must have, should have, could have or won't have.
  • Rough metrics – If you are seeing the number of must have stories decreasing, or an increase in the number of stories not in focus, it may be time to recalibrate your focus against the public's ideas. Why? The volume of stories and the trends they reflect represent the wisdom of the crowd regarding the perceived need or value the product can provide.

Currency in product planning
Because the Focus Story is a marker as to where the project is thought to be moving toward, several of these markers serve as a reference as to gap between the development of the product and the demands of the product users. If, on a regular basis, the product owner takes ideas from the wise crowd, much of what Clayton Christenson describes in his work on Disruptive Innovation is put into action and keeps the innovation/enhancement planning cycle in consistent action.

Moving Agile QA consistently across a large effort
QA, using the Focus Story can make valuable contributions at the highest level of planning and grooming. The Focus Story provides guide rails to Agile QA and test, particularly across large Agile efforts. In planning, QA's ability to sustain a consistent level of stories as each story moves from backlog, to release plan, to iteration plan and into a sprint because the information regarding the goal and core priority around DONE as well as the time the goal is to be done by remains explicitly the same. This is critical as it the possibility more than one team may be working on parts of a single large story. It is more likely that a story, once decomposed or split, will have its parts worked on in separate sprints. In both cases, the common Focus Story reference point guides each child of the parent story through these gates.

The first gate, quality assurance, supports entry into the backlog itself by measuring the story's ability to discern the goals and DONE. In order for a story to progress beyond the backlog, qualitative aspects of assurance must transform into quantitative inspection of the story's feasibility in order to be in a release. This uses the primary goal of the Focus Story and its definition of DONE to ask and answer what value the story delivers and how it supports the primary goal of the Focus Story. Note that a story does not need to be rejected, if it cannot be measured quantitatively, and that the product owner can choose some other way to accept the story. Here the Focus Story serves to baseline the qualitative decision. While this article has talked about Focus Stories as a useful gauge, other writers, such as Mike Cohn, present comparable thoughts from a team perspective. His most recent book "Succeeding with Agile", Mike talks about transition from discernable value of a story to testable, measurable criteria or "Conditions of Satisfaction " in his discussion of "Specification by Example." As always, Mike's work is worth a thorough read and "Succeeding with Agile" will help those interested in diving deeper into a team centric discussion of "Conditions of Satisfaction".

Develop and deliver reality across the board
The cliché "Perfect is the enemy of good" should be a mantra for changing the way we think about, test and develop. The larger the effort, the more important this mantra is to sustaining consistency across teams. Agile develops what is valued and does so as perfectly as possible. This will require that large efforts put some value on coordinating what they build and to what they build. Focus Stories along with Agile QA give muscle to this act of collaborative coordination, as the core of Agile QA is not to test everything to specification, but to make sure everything of value to the product owner works perfectly.

Focus Stories guide user stories to express the value so it is understood and worked on at all levels. Specifically, if we do not know how to deliver the value then we do not build a mistake and waste money, time and our credibility hoping we can. This means when one stream of delivery is blocked by the inability to measurably test what one team is to deliver, then other teams must be aware of that limit and adjust their work accordingly, by either reducing the work delivered or finding alternative ways to deliver the value requested.

All of the above creates a testable bed of examples/criteria/specifications sufficient to have the value of the story accepted by the product owner. Depending on your product environment, you may or may not be ready to ship. You may or may not have other tests, development, integration, and downstream work to attend to. Do not worry about it. Get what you have in front of you done and done well.

Silver bullets are for cowboys and vampires
Also, keep your optimism and idealism in check. Nothing here is even close to a silver bullet. What we have gone over, at a high level, are some simple ways to use existing information for filtering out what is immediately important and for maintaining consistency across a group of teams. In the fourth and final installment, we will talk about using this as a crude compass to steer large efforts in the fog of emergent delivery.

Mike Dwyer is a Principal Agile Coach at BigVisible Solutions. He is a Certified Scrum Trainer and his practice focuses on transforming organization's product lifecycle into hyper-productive Agile teams.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.