You are the Product Owner for a Scrum Team. Your team has just released a brilliant feature they have been working on for months: Change History. Change history allows to track who made what changes to users. Everybody is excited and happy the feature will be finally shipped.
Users love the new feature, but they immediately provide feedback. After the feature is released, you end up with a list of 10 small improvements you want your team to work on.
Translating the list of improvements to User Stories
You start writing User Stories, but boy is it a lot of effort. It is difficult to write clear User Stories for these changes. The improvements seem so small and simple, why is it so hard to capture them in User Stories? You also get the feeling that you are repeating yourself. After all, you already have great User Stories for the features these improvements belong to.
For example, you notice the user change history overview takes about 10 seconds to load, so you start writing a User Story:
As an administrator, I want the change history overview to load quicker, so that I have less waiting time.
You also notice there is no hover state on the filter row of change history, even though this violates UI guidelines. You try to capture this in the following User Story:
As an administrator, I want the filter row of change history to have a hover state, so the affordance is clearer.
2 User Stories down, 8 more to go. Using User Stories does not feel natural at all. Is there a better way to write these User Stories?
Enter Improvement Stories. Improvement Stories are great for small improvements. You already have User Stories that explain the context really well. You just want to make some small improvements. The User Stories describe the problem you are solving for what user. You just want to make some small tweaks. So you just link the Improvement Stories to your existing User Stories. Now you and your team can easily access the context of the existing User Stories if necessary for deeper understanding. The Improvement Stories get to remain small.
Improvement Story template format
Improvement Stories have the following template:
We have<current situation>, we want to have<desired situation>.
Now let’s imagine we rewrite the two User Stories with this template.
Currently the change history overview loads in 10 seconds, we want it to load in 2 seconds.
Currently the filter row of change history has no hover state, we want it to have a hover state.
Much shorter than the User Stories we have written before right? Also much easier to understand and work with. Everybody understands what needs to happen and superfluous information has been removed.
Now writing those 8 other improvements will take considerably less effort than with User Stories. Yet you will have the same, if not more, clarity than if you would have used User Stories.
Improvement Stories do not replace User Stories. Improvement Stories form a great addition to communicate small changes. You also prevent duplicating of effort, because you can link the improvements to the existing User Stories.
Improvement Stories are great for capturing small improvements
Improvement Stories offer a number of benefits for small improvements compared to User Stories:
- Take less effort to write. You can still provide the same context as a User Story. You just link them to the affected User Stories so people can dig deeper if necessary.
- Prevent duplication of effort. Why repeat yourself when you can link to existing User Stories that already describe the context really well?
- Easier to understand. In case of small improvements, User Stories can easily become convoluted and even generate confusion. Superfluous information may cause people to overthink.
- Allow you to keep things simple for simple things. Make sure you do not use them for bigger changes, because then User Stories will work better.
- Complement User Stories really well. Improvement Stories work great in conjunction with User Stories, but do not replace them.
The main downsides of using Improvement Stories:
- Improvement Stories focus on the solution. They are not good for discovery. You use them when you want to implement a simple solution and it is obvious why it needs to happen.
- Improvement Stories are not versatile. They are only suited for small changes and when you know exactly what needs to be delivered.
In summary: Improvement Stories are a simple alternative to User Stories. Improvement stories are better suited for implementing small changes. When you notice it is difficult to write a User Story for a small improvement, try an Improvement Story instead. You will save time and the Improvement Story will be clearer for your development team as well.