Last week I had the pleasure of running a user story workshop for a group of very experienced folk with a broad range of backgrounds and skill sets. We convened the workshop to discuss the challenges that present themselves when we apply user stories for the first time on a real project.
The conversation was broad ranging but, since a number of people have told me that attending the workshop was valuable, I’ll try to capture some of the key issues.
What is a user story?
User stories have been described many times and in many ways, including the following:
- A requirements elicitation technique
- A prioritisation technique
- A planing technique
- A means to capture a requirement
- A means to defer capturing the requirement
- A unit of scope
- A question waiting to be asked
To some degree each of these are true. My personal favourite definition is “a promise to have a conversation”. This cuts to the heart of the approach. We use user stories to capture the need to dig deeper later. Early in a project we find out lots of desires about the end product. Many will grow into deployed features but many will never be built. Some may be valuable but turn out to be too expensive. Others may turn out to represent little value so be lost.
By having a very low fidelity mechanism for capturing requests we can see the shape of a product and the range of needs without delving into detail.
What is a story’s life cycle?
In the workshop I used Ron Jeffries model of a the life of a user story:
Over a story’s life it will move from being an idea to being captured on a card i.e. deferred. At some point we will want to know more so we go talk to the appropriate people. We may capture this conversation in any number of forms including notes, diagrams, wireframes and examples. The final stage is to confirm that the story is satisfied. We typically capture acceptance criteria for a story before commencing development, this may or may not be automated as a set of tests. Following development we will demonstrate that the user story is satisfied.
What remains of a story post development?
We should be able to remove all trace of the story post development. Any long life artefacts will be created as a result of the story i.e. these are part of the acceptance of the story.
Stories are a poor solution to documenting a system because of their fragmented nature. One approach I have used in the past is to provide informal, live, versions of documents during development. These can be polished (if necessary) at the end of development. This approach emphasises documenting the right thing at the right time.
Who is a user story about?
User stories are written on behalf of users but also stakeholders. This means that we can express what are often referred to as “non-functional requirements” as stories for a stakeholder e.g. As the Security stakeholder I would like to use 256 bit SSL so that the site is conformant with our security policy.
We also write stories for personas, this allows us to place appropriate emphasis on the class of user who we are building the feature for and ensure that the specific user types goal is the focus rather than something more generic.
We delved into other areas I’ve written about previously too such as MMFs. I hope that this triggers some useful thinking but for me it’s always worth remembering why we use User Stories – to defer analysis until the right time while retaining a view of what the future might look like.