Check-list for the quality user story for effective Product development

INVEST characteristics, User story format, 3 C’s of user story

The Problem statement

Before we dig into the subject, let’s first highlight the problems faced by the product development teams:

1. Different departments of the product company have their own accountability and expectations from the product development team and expects the results faster than ever.
2. All team members of the scrum team are not aligned with the same context at which the support/ operations department have.
3. Contextual challenges being faced by the Product Manager (PM) while converting business requirements into respective product documentation along with aligning the scrum team members.

It is said that think big but start small. I think the concept of the user story follows the same philosophy. It also helps teams to follow Agile methodology to produce iterative output sprint by sprint. User story is also a building block of any major feature/ functionality in the product.

The characteristics of any valuable user story are:

1. I-Investable — A user story should be well enough that a team should be able to invest their time and resources.
2. N-Negotiable — A user story should be well enough that a team can negotiate on it. Team should be able to discuss around its impacts, edge cases and expected behaviour.
3. V-Valuable — As user story should be well enough that it must add some or significant business/ technical value into the product. The scrum team should be able to bank on it.
4. E-Estimable — There has to be start-time and end-time of each and every story on which the scrum team should be able to estimate. Now this estimation can be in the form of no. of hours/ story points, depending on the teams’ consent.
5. S-Small — A user story should be small enough that a scrum team can deliver within a sprint length. Idly, in any scenario the user story cannot be more than the size of the sprint.
6. T-Testable — A user story should be testable by the QA team members. This is mainly true for the business/ user side stories. While in case of core technical/ infrastructure stories this is not always true.

Format of the idle user story:

As a {User Role} I should be able to do {Specific Action} so that I can achieve {my purpose}.

Acceptance criteria, a point which defines the status of the user story. To dive more on this you should read detail view with appropriate examples.

3 C’s of a User story for the Scrum team

1. Card — A well defined user story declares its intentions among the team members to keep all align for its value.
2. Conversations — Once all team members are on the consent about the definition of the story then series of conversations/ discussions gets execute among the team members. The output is that they will come to the conclusion about the ‘What’ and the ‘How’ part of the user story.
3. Commitment — This is about giving commitment to the Product Manager (PM) and stakeholders about the specific user story. The way of commitment is depending on the scrum team.

Conclusion

In my 3 years of experience exclusively in the product domain, I have experienced user story as a building block of the product. The quality of the user story defines the commitment of the team for continuous value addition in the product. As this helps all the stakeholders related to that particular user story on the same page and expect the expected output. If you follow the INVEST rule, proper format and the 3 Cs of the user story then I am sure that it will increase the probability of achieving the sprint goals of your product.