Product Backlog decomposition
Product Backlog (a value-prioritized to-do list) managed by the Product Owner is made up of product requirements. A requirement is a functionality or a feature that we want our product to have. The requirement must earn the right of your investment. The scope of Product Backlog depends on the size of its components (the requirements). We’ve already mentioned that in Scrum we break the work into the smallest units possible. Why the smallest? Firstly, the chunks must be digestible for the team within a Sprint, since Scrum is about permanent, consistent increment delivery. For this reason, the amount of work to do must be viable for the team. Secondly, we gain speed by thinking ‘small’. It reduces complexity, as more is known. The smallest product requirement is a user story. What is a user story?
What is a user story?
A user story is a description of a product functionality written from the end-user’s perspective. It’s a really useful way of gathering product requirements that the Product Owner conducts during their meeting with customers. In a different post, I’ve said that Product Backlog is never complete, so these requirements are gathered, re-estimated and re-negociated until the product is released.
What is a user story like?
A user story is usually one-sentence length statement. An example format is:
As a <user (class)> I want to <action> so that <benefit/value>.
As a English learner, I want to save the vocabulary sets I’ve created so that I don’t loose access to them.
Another format of a user story might go as follows:
As a <specific persona>, I want to <goal or need> so that <why?>
As John I want to purchase any item on the webpage without having to register so that I could make purchases faster.
A user story should be written in a simple way, meaning it doesn’t contain any jargon or technical language used by developers or the product owner. It’s all about reducing complexity and misunderstanding. All must be crystal clear. The message must be direct, clear and to the point. We’re writing it for a user after all. Hence, it should be understandable for a non-technical person.
It’s a requirement that is to bring value to our customers or product users. It’s always written in the first person singular – ‘I’. As a result, every member of the team that is supposed to do the work is able to somewhat feels like an end-user. That way it’s easier for them to evaluate the value of a story. One story gives one value to the product. In other words, it’s one functionality of the product, one action of value that an end-user will achieve.
A user story card content should be direct, succinct and specific. It works as a stimulus for a discussion which is pretty hard when the story is complex.
The 3C’s model
Qualities of a user story: INVEST
INVEST is an acronym for qualities that a good user story should have. Bill Wake first created it. So, a user story should be:
Independent: The story doesn’t need any other story to implement it. It’s a separate unit, separate value to provide. If it turns out that stories are dependable on one another, then we can combine them together.
Negotiable: The Product Owner and Developers talk a user story through and expand on the story’s nuances and details. They negotiate the scope till the story doesn’t leave the Product Backlog.
Valuable: The story provides value to people.
Estimable: The story must be written in such a way that it’s possible to estimate its size – the effort that developers need to make to deem it done.
Small: It’s easier to plan and estimate a small story. We learn more as we break a story down into smaller chunks.
Testable: We need to test the story to tick it done.
