You have a product requirement, how should you go about breaking into user stories that effective for teams to work with ?
Utilize the I.N.V.E.S.T Model. Steps below.
- Independent: We want to be able to develop in any sequence.
- Negotiable: Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
- Valuable: Users or customers get some value from the story.
- Estimatable: The team must be able to use them for planning.
- Small: Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
- Testable: Document acceptance criteria, or the definition of done for the story, which lead to test cases.
- Better stories from a refinement process: Your user story goes through a process that refines it to an optimal point for execution
- Pragmatic Simplification: Remember, we must simplify things but not not beyond a certain point
- Pragmatic approach: Always simplify user stories to a point that human and technological resources can optimally understand, implement & test the requirements with ease. No need to over-simplify things to the level of a 5 year old.
- Product teams waste time and resources often over simplifying things.
- Needs driven user stories created: Best user story format are the simplest ones that quantify a user’s needs clearly – both quantitatively and qualitatively.
- Well defined S.M.A.R.T stories: User stories also come out as short, simple descriptions from the user’s / customer’s perspective who desires the new capability. Example:
AS A USER ____<type-of-user>________
I WANT _______<some-goal>_________
SO THAT ______<some-reason>_______
- Stories with a clearly defined and agreed acceptance criteria to be worked with Engineering and Product teams. E.g. below.