Understanding what you are working on, and more importantly why you are working on it, is at the heart of business success. User stories play a central role in bridging the gap between the customer and the delivery team while promoting a culture of collaboration, innovation and shared leadership.
Back in the day, Business Analysts would gather the requirements piece by piece, then staple them together in one, chunky file, which would be divided back into smaller deliverables that fit into the team’s iterations. The sequential sense of structure rings a bell? Waterfall projects are famous for that. And they’re something modern, dynamic businesses cannot afford. To survive in a highly competitive market, they need to remain adaptive to changes, receive feedback as quickly as possible and make the most of their time and resources.
So the agile world turned over a new page, more precisely, they ripped one out of a post-it note block. A humble post-it note now represents a single piece of customer value in place of a monumental document filled with detailed technical requirements. It harbors a user story, an end goal of a particular request.
Normally, user stories are no more than a couple of concise sentences long, but after reading the story, the delivery team should know what they’re building, why they’re building it and for whom they’re building it. This is the power of user stories; the fact your team can understand the value it brings to the customers after a mere glance over the card.
The Purpose of User Stories
Now, regardless of whether user stories are written on physical or digital cards, you should resist the temptation to think of them as features. They’re not features, nor are they solutions to your customers’ problems. The main purpose of user stories is to frame the idea of how your customers would benefit after the story has been completed. To uncover a problem, a need or a necessity of your users.
And catering to your customers is everybody’s job. The Kanban Method strongly encourages leadership at all levels, meaning all of your team members should contribute to the evolution of a user story. Everyone should chip in their perspective on the problem until the most feasible, useful option has been sourced.
This way, not only will you end up with the most valuable user story, but you’ll also spark engagement and motivation within your team, with people joining forces together to better understand those they’re ultimately serving.
Writing User Stories: Staying in the Problem Space
Some teams jump into the solution mode prematurely, forgetting to dig deeper into the problematic of what they’re trying to solve.
Put yourself in your users’ shoes. What is it that they need or want? What is the value they need to be brought? As a product manager, you’re in charge of making everyone understand what and why they’re working on, whereas your team figures out the how part.
At the moment of its creation, the user story should be exposing the end goal of a request while remaining as flexible as possible with regard to execution – you don’t want to lock your delivery team with a single formula of bringing the story into fruition.
Here are some mandatory questions you should ask yourself before putting pen to paper:
- Who are we building this for? Your team should have a shared understanding of the persona for whom the story is being built. This way, you’ll be able to make your decisions with far more accuracy.
- What is our user trying to achieve? Remember you’re trying to reveal the user’s goal, not the feature they’ll use. The answer to this question should be implementation-free; it is the delivery team that will work out the possible options and technical details afterward.
- Why are we doing this, what’s the overall gain? The benefit to both you and your customer should be crystal clear. How will this user story enhance your business strategy, improve your product and support your customer’s aims?
Approach writing your user stories with these questions in mind, and you’ll end up with a few goal-oriented sentences that effectively set the stage for further conversation.
User Stories in Action
Note that a ”user” doesn’t necessarily stand for an end-user in the traditional sense. Your support team can be a user, too, and their request for an internal change could very well turn into a valid user story.
Regardless of its origin and nature (internal or external), each user story goes through the process of evaluation, analysis and prioritization. Once approved and written, the story comes to life in the Kanban backlog where the product manager assigns it a Class of Service (CoS) – a prioritization criterion that specifies how stories interact with each other and how the team is going to treat them.
Once the story is picked from the backlog, it progresses across the board as it meets its quality criteria. These criteria need to be defined beforehand, both to signal when a story is ready to move onto the next step, to pinpoint the moment in which the story is already potentially releasable to our users, and to ascertain when it is done for good.
Defining Done: Supporting Continuous Delivery
Continuous Delivery (CD) enables teams to rapidly deliver value with less risk. It’s an approach wherein each developed user story can produce a releasable byproduct. This means that there will be a point in your workflow where, even though the story hasn’t been fully completed, it is ready for delivery to your customers.
But in order to release a task, we need to establish a threshold a story has to cross to be considered done. Our story must fulfill a list of criteria and reach a pre-set level of quality before it progresses onto the next step in the workflow. This is what we call the Definition of Done (DoD) – an agreed-upon evidence of completion.
The Definition of Done is a prerequisite to Continuous Delivery. Without knowing when a user story is releasable to our customers, how would we know when to ship the tasks out to them?
Let’s illustrate our example on the following user story: ”Enable users to analyze data without leaving their boards’’. We’ve split our process in the following way:
- Analysis
- Development
- Development Done (Deliverable)
- Code Review
- Code Review Done (Deliverable)
- Testing (Deliverable)
When the task has progressed past the Development Done state, it is already potentially deliverable. Code Review and Testing will follow, and these activities are mandatory before the task has been considered complete for good.
Each process state features a list of criteria that needs to be checked off before the story can move forward. In Code Review, for example, the source code should first pass all automated tests. Then it should be verified against the guidelines for structure, performance, test coverage and readability. Finally, the code gets approved and deployed for testing. Without crossing off these requirements, our Definition of Done wouldn’t be satisfied and the story couldn’t proceed further.
Agile businesses across the globe are using Nave to analyze and improve their workflow performance. Try our versatile range of analytical charts for free on your favorite project management platform.
Building Fit for Purpose Products
User stories provide us with a user-focused framework while developing collaboration, engagement and truly fit for purpose products.
Start by capturing your user-oriented goal, then work alongside your team to refine and specify the ways of achieving them.
Once your team knows what and why they’re working on from a mere glance over a post-it note, they will grow more self-managed and better suited to serve your customers.
