Improve Measurably with Improvement Stories

One of the continuing challenges we see with some Scrum teams is a lack of improvement in how they work over time. There are many reasons for this, however continuous improvement is the cornerstone of Lean thinking, and the reason we have a retrospective in Scrum.

There are many ways to improve. Lean thinkers advocate the A3 plan for improvement, an excellent way of thinking about larger improvement efforts. You will often hear Lean thinkers talk about “Kaizen events,” Kaizen is Japanese for improvement, and these events are focused efforts to implement improvement. In Lean, Kaizen is a mindset, the search for improvement is continual and a critical part of day to day work of everyone.

In the software community we have numerous good ideas for improvement including Retrospectives, Devops, and automation.

However all improvement starts with deciding to value making the improvement over producing something else, like a feature or a bug fix. This is usually where the problem starts. Teams and Product Owners tend to value new functionality over improvement. From the perspective of a long lived product development effort, every improvement made is an investment that pays off for the lifetime of the product. For example an improvement that saves a team member 10 minutes every day may seem too small, however if that 10 minutes is saved over a 2 year period, that adds up to about 5000 minutes or 83 hours. That’s more than two weeks of productive time that can be spent on more valuable activities. A recent study of the most productive software developers at Google found that they spent approximately 1/3 of their time building tools to improve or automate their work environment. If the best of the best spend 33% of their time sharpening the saw, then shouldn’t the rest of us should make similar investments?

Changes to Scrum that prioritize improvement

Jeff Sutherland, the inventor of Scrum, in discussion with Lean expert Hugo Heitz realized that Scrum teams weren’t realizing their potential because they didn’t proritize improvement. Since then Jeff has advocated the pattern “Scrumming the Scrum” where teams use the Scrum cycle to improve Scrum. The twist is that the improvement is the first thing the teams do, before working on any new functionality. To implement this change the Scrum board gets another swim lane, the improvement or kaizen lane.

By breaking out the improvement in its own lane and putting it a the top board, we attach the visual and social importance to improvement. We are making a clear statement to stakeholders that investing in improving how we work is more important then any one piece of functionality.

Describing incremental improvements

User Stories first emerged from the XP community in 1998 as part of the planning game. Over the past two decades there has been much work on improving User Stories and Acceptance Criteria. This thinking has clarified both the mechanics of User Stories and the value of the different features of the format. There have also been a number of variations developed. As the Agile community refined User Stories, it also borrowed good ideas from the EVO methodology developed by Tom Gilb. Gilb defined System Qualities to specify needs the system must meet that were not features (non-functional requirements).

To date the Agile community hasn’t really defined a good way of describing improvements. The Lean community has A3 plans that are very are useful but often are too large to fit in a Sprint. The A3 format also tends to be a mini project with a number of changes, deliverables and measures, while in Agile and Scrum we use iterative and incremental delivery. So we need a way to define improvement that leverages iterative delivery and our previous learning about describing user and system needs.

What is an improvement? This is an interesting question. Is it a feature? Maybe. Is it a process change? Possibly. Is it a tool? Could be. Is it a social agreement? The interesting thing about improvements is there is a wide range of things we may do to improve our situation and how we work. Given there is such a wide range of possibilities, this is similar to the Feature/function in User Stories. So let’s look at how we can leverage user story thinking for improvements.

User stories consist of 4 parts:

1. The user role
2. The feature or function
3. The benefit or goal we are trying to achieve
4. A definition of done in the form of Acceptance Criteria

In more general terms we can say that user stories are of the form Who, What and Why. User stories are powerful because we bookend the thing we plan to build with two important pieces of information, who is going to use it and why they want it. This means we need to find an actual user and validate that they really do want the functionality. We also need to understand why they want it in order to prioritize it against all the other things we might do for our users.

Looking at the work of implementing improvements we see a similar need. There are many different improvements we can make, how do we prioritize them? Who benefits from the improvement? What benefit do we expect to receive? How do we know we received the benefit? Given these questions are similar to questions we have  answered with User Stories we can leverage this thinking.

Measuring Improvement

While it is great to say we have improved, it is more interesting to say we have improved by a measurable amount. If we are investing time and energy in improvements that could be spent on functionality that generates business value, then we should try to show how improvements provide quantifiable benefits. To define a quantifiable improvement we need to determine:

• What we are measuring
• How we will measure it
• The current state
• The (anticipated) improved state*

^{*this is likely just a guess}

By making clear statements about measurement we force questions about methodology and we make it more transparent how we intend to quantify the outcomes.

Creating an improvement story

Defining “who” in an improvement story:

Since improvement stories may impact team, process, stakeholders, users, management, we have a broad number of potential roles. Choose the role most closely associated with the benefit, and involve them with measuring the improvement.

Defining “what” in an improvement story:

The improvement needs to be do-able. This means if we pull it we can get it done within the Sprint, and we can see a result from the work that provides a benefit we can take advantage of next sprint.

Defining “why” in an improvement story:

Why are we making the improvement? What waste are we eliminating? What aspect of work is improved? What increases do we expect to see for the defined Role?

Knowing when we have improved:

It isn’t enough to say we have improved. We need to find ways to quantify the benefits. How can we measure the improvement?

Example improvement story:

During their retrospective, a Scrum team comes up with a number of improvements they could make in the next Sprint. The team decides there are two improvements they will tackle in the next sprint, reducing the time to install new builds onto the QA server, and improving communication with another team who they rely on.

The team crafts the improvement story together during the retrospective.

Starting with “why”:

The team defines the expected benefits, with testers talking about the time wasted waiting for a new build and developers complaining about getting hassled by testers for a build, having to stop working on a feature to run through a bunch of tedious manual deployment steps. Both developers and testers will benefit, so they decide to write the improvement story both ways for fun. The testers do some quick calculations and determine that on average they will save an hour per day per tester. The developers determine they will save 15 minutes per day per developer. Both developers and testers expect this change will improve team working relations by eliminating at least 2 or 3 conflicts per week, reduce multi-tasking and make the team happier.

What can we do to improve this sprint?:

The team discusses the possible solutions they could pursue, from implementing a new build server to automating database configuration. As a first step the team agrees to write deployment scripts that will automate copying the current build from the development build server to the QA server and run a smoke test. Since database changes are less common they choose to defer automating database updates to a future improvement. The team writes up the improvement story from the tester point of view:

And then they write it from the developer point of view:

In creating these improvement stories the team has agreed on what they will measure and how they will measure it. By agreeing to put red postits on the Scrum board every time there is a conflict the team creates visibility about the aggravation (or lack of) caused by the friction of the current system.

The team realizes there is an additional important benefit from making the improvement. Not only will it eliminate wait time and frustration for team members, it will also speed up feature development, since testing, bug fixes and validation will happen in a shorter timeframe. The team likes this benefit but isn’t sure how to measure it, so they leave it as a topic for next retrospective.

Sizing and Decomposition

As with User Stories, Improvement Stories can be written at both a high level and detail level. They can be sized using story points, and can be decomposed into the specific tasks the team needs to get the Improvement implemented.

Improvement Story Templates

There are two different templates you can try for creating improvement stories

Template B “Start with why.”

This template emphasizes the importance of why more than the standard template.

Template A – What What Why

Template A is likely more familiar to most people who are using User Stories.

We hope adding improvement stories will help you implement continuous improvement within your team and organization. Stay tuned to Innovel for additional writing and examples on improvement stories.