During the various workshops and trainings somebody asks: “how do you know that story is well written and ready?”. The first reaction from other attendees in the room is usually something in the following lines: it depends on the team, their familiarity with the product, the work needed to be done as well as maturity of the product owner.
True, but what if there are some characteristics of a story, some elements that all good stories should have to survive the implementation team’s scrutiny? In our company, we tend to follow the INVEST model. As usually in the IT world, the INVEST is an acronym for:
It must be noted here that this model is known across the Agile community and it is not invented by our company, we just find it very helpful and follow this simple model wherever we can. Lets have a closer look at each of the characteristics…
Ever found yourself in the backlog dependency hell, where you had high level stories (also called epics) and a bunch of interdependent stories that made the planning and estimation a complete nightmare? That’s exactly why the stories should be independent of each other as much as possible. If you have too many dependencies between the stories, try to think out of the box, regroup the stories in a different way, join them into a bigger one or slice them differently into smaller and different chunks. This effort to remove the dependencies will pay off big time, when you start the planning and estimation.
Users, customers and the implementation team need to be able to negotiate and agree on all details of the story. The “negotiability”of a story can be rather hard some times, especially when you work on software close to the operating system, without a UI or direct interaction with the users. It takes a lot of explanation and negotiations why exactly this story is important in the whole picture, but be ready to do that – your software is worth it.
One of the key elements of agile is that everything you do needs to bring a value to the customers. Its good to include the value part in the story description, so agile team members who will work on the implementation actually know why it is important for the customer, what value it brings. Surprisingly, knowing “why” many times significantly influences the implementation of the story and the developers take a different approach compared to the situations, where they code “blind”.
The team members need to be able to estimate the story, at least in ballpark numbers. If you have a nicely written story, but the team members don’t know what to do and how to implement it, such story turns out to be useless. Try to create small enough, self-contained stories that are within the domain knowledge of the implementation team.
Having worked on not so common platforms such as mainframes, missing domain and product knowledge is many times a killer of good estimation. If you work in such environment, try to find creative solutions on how to estimate, use experts, pair programming, estimate reviews or whatever will work for you in your context. Your goal is to have the stories estimable in the team that will implement it and not estimate by some external experts. If your team is missing a domain or product knowledge, help them to gain it, so they can estimate the stories themselves and be able to commit to the estimate.
This aspect is closely connected to the “Independent” and “Estimable” characteristics above. Big stories are hard to estimate, increase a risk to your sprint accomplishments and you can’t really monitor the progress of the story at the burndown chart, as the story will have an effect on the line only when its complete. Again, we follow a simple rule: if the story will take more than half of a sprint to implement, its too big. Such story needs to be revisited and broken down into smaller pieces.
Finally, all stories needs to be tested before they are accepted by the product owner (of course depending on your acceptance criteria). The cross functional team needs to be able to implement, test and document the story within one sprint, so it is a good idea to include any testing consideration in the story description. The quality assurance people need to understand how the story will be tested, what are the non-functional requirements and if there is any impact on the existing tests.
That’s really it. Well-written stories are the key element and a cornerstone of all successful agile implementation. Such stories will save you tremendous amount of time during the backlog grooming, planning activities and the estimation. While at the first look it seems to be an overwhelming effort to create such story, everyone will get used to it quickly and you gain a lot of time and clarity across the teams and stakeholders.
So are you ready to INVEST into your stories?