Some states are entrances!
User stories are a way of stating requirements. Ron Jefferies coined the meme, the Three Cs to describe a user story. The 3 Cs are:
- card,
- conversation, and
- confirmation.
The idea of a card was to keep the user story short to avoid making the requirement overly complex and to avoid analysis paralysis. Because the card was a short statement of the user story, conversations are required to expose the nuances of the user story (note: nowhere does it say NOT to document your conversations. If someone tells you not to document your conversations, forget them!). Finally, the third C, confirmation equates to testable statements that allow the team to know when the user story is satisfied. User stories might begin as nebulous statements, however, when groomed, a well-formed story provides strong guidance on the business need to be addressed.
User stories pass through four basic states.
- Forming
- Not Started
- In-progress
- Done
Forming – Regardless of when a user story appears, the story needs to be captured and placed in the backlog. As stories are being gathered and formed, most teams (including product owners) perform a high-level triage that can include a quick rejection of the story or a tacit acceptance and prioritization.
Not Started – Many activities occur while a story sits on the backlog waiting to be started. This is often where the conversation about the stories begins and where the bulk of grooming occurs. As stories work their way up the priority ladder they are often split into more manageable chunks. It is not uncommon for parts of a user story to be rejected as they are split. Also, note that whole stories can be rejected or removed from the backlog if circumstances change.
In-progress – The team pulls and accepts stories into the sprint or active queue. This is where the next level of magic happens and the team converts perfectly good words into a deliverable that has business value. Once a team accepts and starts working on a story (or any other piece of work) the base assumption is that the work will complete (conservation of flow – Actionable Agile Metrics). While once a team starts working on a story actively it will typically complete the story, there are other possible outcomes. Stories can split when the team discovers the work is bigger than expected or includes other features. The new stories need to be groomed and prioritized just like any other piece of work. When a story reaches the hurdle described in the definition of done and has met the confirmation criteria (two very different hurdles) the product owner will accept or reject the work. Acceptance does not stop the generation of new stories or work items based on the knowledge generated by completing the story. The rejection of work at a demo should be VERY rare if product owners are actively participating with the team AND the product owners are from the business. Where rejections occur (other than very occasionally), I generally see either an uninvolved product owner or a proxy product owner – neither is a great idea.
Done – The story is marked complete and removed from the backlog.
User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality. That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!