What are user stories?

User stories, as the name implies, are pieces of information that indicate a user centred requirement that when put together, will form a new system behaviour of the end product. A user story is an integral part of the product backlog, team backlog and the sprint board.

Simply put, companies need to make money, and for that to happen, business analysts, sales and many other stakeholders need to communicate the requirements to the scrum teams.

Companies make use of known communication systems to effectively communicate requirements and secure timely delivery in adherence with the original request.

The ideation of user stories comes from the need to create a more informal communication that is actionable in an estimable amount of time. Basically, what worked in the past has no place in the ever changing, ever growing present. Depending on the type of venture or enterprise, business requirements and KPIs can change in such a way that would require companies to be flexible and adaptive to create the best competitive advantage in their industries.

What makes a user story great?

As Bill Wake puts it, a great user story follows the INVEST model

• Independent – The sequence for building a user story and its updates does not effect another.
  
• Negotiable – The scrum team decide how to implement the user story. No preset way of doing so.
  
• Valuable – Delivers value to the end user.
  
• Estimable – The scrum team can estimate the time to deliver the story relative to estimation metrics.
  
• Small – Achievable in one sprint.
  
• Testable – No user story should be committed to without acceptance criteria

Let’s break down this user story!

‘As a user…‘ The story starts with these words. Here, the team had decided to use the ‘user’ term only to refer to the end user. The user could also be an administrator or a developer or a stakeholder such as marketing or sales.

Identifying the right user would allow the team to develop the requested functionality and create user tests. This user story meets the DoR (definition of ready), because it follows a format that ensures complete information for converting the story into technical requirements.

‘I want…‘. These next words indicate to the team what the user wants to be able to achieve, and here is where the team looks for a specific goal that the user wants to be able to achieve which would complement the overall user experience. In the example provided, the user would like to be able to set custom market movers parameters so that they can have a personalised watchlist of the trade-able instruments that are causing change in markets.

‘So that…’. This is an integral part of the conversational user story format as it indicates the monetising reason to satisfy the user needs. What will the user get from achieving their goal? What does it mean for the business?

It gives an immediate understanding of why building the feature part of the user story is profitable for the user and the business. In the example above, the user wants to be able to take advantage of short term trading (A.K.A swing or day trading). Market movers filters can help the user do this by eliminating missed opportunities on trending markets.

The above mentioned user story format aids the scrum team to convert stories into technical requirements. Technical requirements need to be specific for the team to understand what exactly they need to build. The above user story structure ensures information is correct and complete, however you may notice that the user story is not technical and specific enough to be able to create a proper technical requirement.

The user story asks for custom movers for the users of the app, so that they can create a list of instruments that fall under their interested trends. However, user stories are not technical. This means that sometimes, teams need to break down a user story into sub-tasks.

How do you build subtasks?

---

Well subtasks are usually more technical pieces of information than a user story. They are the breakdown of user stories that represent the amount of effort a team will take to achieve the parent user story.

Through the many years working as a product owner, I’ve seen many scrum teams struggle writing qualitative subtasks.

Well here’s how we made our subtasks great!

#1

A subtask should resolve one or more acceptance criteria defined in the user story. If it’s not resolving at least one acceptance criteria, there’s a high chance your sub-task is irrelevant to its mapping. Keep building subtasks until you have a subtask for each acceptance criteria, you don’t need more, and you must not have less.

#2

We wrote test scenarios for each user story.
Test scenarios, allow the scrum team to test their work from a user perspective.

That’s all there is to your subtasks and you can use any format for them.
Below is how we broke down the subtasks for the example above. Notice how we always looked for ways to improve visual communication. We used square brackets at the beginning of each subtask so that the scrum team members can quickly visualise their responsibilities:

From the screenshot above, you can see that for this particular user story, we had a subtask for each acceptance criteria and an extra subtask to request the designs from the design team. The scrum team measures user story achievement through subtasks. When all the subtasks are ready, so is the parent user story.

What makes a sub-task great?

---

As we have seen above, a subtask that resolves one of the acceptance criteria of the parent story, is a quality subtask. This is because it gets the scrum team a step closer to resolving the whole requirement.

Enabler Stories

---

Unlike user stories, enabler stories are information representation of system enablement. Enablers pave the path for the architectural runway. Written either in technical terms, enabler stories focus on investigation, configuration of systems, technical debt and other. There are different types of enabler stories and we take a look at some of the types below:

Spikes

---

A spike story is a user story that creates no new system behaviour, but identifies the unknown in uncommitted tasks.

An Agile culture requires all members within the company to work in a scrum manner, and through such practice, product owners, together with their managers and the different stakeholders, create requirements using proven techniques to ensure all requirements are correct and complete. Gathered requirements may be ambiguous at first attempt, therefore the scrum team could not commit to them. Scrum members utilise SMART goals or OKRS to deliver qualitative and ambitious goals.

Scrum teams evaluate yet do not commit to unclearly defined objectives. The team does not commit to complete or work on these tasks before more information is provided. In certain cases, product owners and stakeholders refer to the team to do some research to get knowledgeable about what and how to achieve an objective. This research requires time and outcomes, which is why agile teams create SPIKE stories to incorporate into their sprints.

A spike story is a story that creates no new system behaviour, but identifies the unknown in uncommitted tasks. Scrum teams create spike tasks to conduct research and increase knowledge value that will help to achieve the objective in question. At the end of a spike story, team members will document their findings and propose a solution to complete uncommitted tasks.

Refactors

---

Refactors are stories for the improvement of current systems and technical challenges.

Everyone can speak about agile culture and development from a theoretic perspective, however in the practical real world enterprise, things happen a little different. Companies go through roles terminations and new on-boardings, promotions and transfers of human resources, migrations and integrations of new systems. All these changes in a company cause current and new system behaviour to be altered and defected.
While documentation is a key factor to maintaining system health through times and updates, the need to refactor will always arise due to aforementioned changes. Being prompt and planning refactors is as essential as it is to deliver new value to the business, why? Because like every other debt, technical debt has to be paid at some point. Refactors are a way to solve technical debt.

Incidents

---

An incident ticket is not a story in itself. It is used by scrum teams to report defects. Incidents are worth mentioning for several reasons:

#1. Happen everywhere

No matter how well organised a team is and how harmonised the SDLC is, system defects will always happen at some point. This means that incident tickets are an integral part of planning and sprints. After all, completed user stories are among the main reasons for defects in the system.

#2. Urgent

While we plan our stories and we story map to deliver a piece of new system behaviour, agile requires adaptation to change, for such reasons, some defects arising before, during and after a sprint plan may have precedence over other tickets due to their level of urgency. Incidents are reports of some level of user experience impairment and some may even disrupt the user in such a way that they wouldn’t be able to reach their end goal.

#3 Disruptive

Writing user stories to break down product requirements into technical requirements is a great way to achieve the desired result. Backlogs could get inundated with defects happening anytime, therefore need agile planning. Because defects can occur for multiple reasons, backlogs could get inundated with defects. Unless a good plan to resolve defects is laid out, scrum teams could spend sprints resolving due defects. The below figure shows how defects can be planned. A tested plan is to resolve only defects and enablers that are needed for the current sprint.

Who writes user stories?

---

Think of it this way! The agile team is responsible to resolve user stories and deliver new functionality promised within that user story. This means that anyone within the agile team can write user stories. However, it is essential that a product owner is assigned to ensure continuity.

Continuity? In what sense? Well, agile teams usually include two important roles, the product owner, known as the PO, and the scrum master. The product owner ensures that the requirements are delivered to the team with the DoR. The scrum master then collaborates with the team to create technical requirements and plan them for the next iteration. Without the correct roles to guard this process, the flow would be compromised.

When do we write user stories?

---

Writing user stories is not a necessary task, yet writing a good user story could make or break the success story of your product. Requirements for a product need to be investigated, collected, discussed and documented. The product requirements will reflect the business goals and KPIs, and for that reason, roles like product owners become important to bridge the gap between business and development. This is where user stories come at hand!

Handing a large document of several requirements drowning in business jargon to the development team has proven to be ineffective in the past. However powerful user stories are, they should not replace the official product requirement gathering during requirement discovery stage, nor should they replace planning events.

User stories are a powerful tool to extract just the right amount of information scrum teams need and gives it focus and context from the official documentation. User stories promote collaboration and conversation between team members and drives timely implementation of user focused new system behaviour.

Sprint planning, is the scrum event in which scrum teams plan the next iteration, typically 2 or 4 weeks long. During a sprint plan event, the scrum team reviews the team backlog to commit to a number of user stories to deliver. There are certain measures that can be taken to ensure user stories are achievable and value is delivered in time. Let’s take a look at these!

#1 User story mapping

User story mapping is the outlining of the relationship between user stories. Remember, user stories are small pieces of user focused functionality and not the entire feature. A feature can have multiple user stories and each story may have its own dependencies. Before jumping into committing to developing user stories, scrum teams need a sprint goal. A sprint goal is everything that the scrum team intends to attempt to achieve in one iteration.

Writing a good sprint goal is not an easy task. I had adapted my teams to a simple strategy which helped them write effective and achievable goals every time, story mapping!

My teams would hold a time-boxed event of around 30 minutes and map the stories out. We played with user stories like they were puzzles pieces to hook up in order to their epic.

Yes, the epic or feature in your scrum board is what maps your stories out, as these are the tickets to business, customer and knowledge value. If a story resolves a piece of the feature, then it belongs to that feature, if a bug originated from the completion of one of the stories mapped to that feature, then the bug belongs to that feature and we sub-bug it to that feature. This not only helped us know what to work on and what to work on first, but also how much work we need to do to deliver the immediate business and customer value.

You probably hear a lot about priorities, but what i taught my teams to take into account when planning their commitments is relevant priority. Now this is a concept that I got grasp of through work experience. We mentioned before that the real world is far from theoretical. When you work inside scrum teams in a company with owners, clients, investors, directors and managers to satisfy, understanding and measuring relevance is crucial to your success and business health.

Relevance is the measure of how far in the timeline or roadmap a priority can go without it becoming irrelevant on par to another priority. It does not deprioritise a priority, rather it gives teams a shift in perspective, equipping them not with the highest priority, but with the most relevant priority amongst a pool of equal priorities of the teams’ responsibilities.

In a real agile company scenario you find challenges. The teams work on gathering requirements, prioritise them, document them, convert them into technical requirements and assign them to the scrum teams in the form of user stories in the backlog. In the ideal world, you would have collected all the requirements for the quarter and have no new priorities pop up for the whole quarter. You would have unlimited resources and all the infrastructure readily set to accommodate team dependencies. You would also have a cross-functional team per feature to ensure parallel delivery in the agile train.

In the real world you have priority features sitting unresolved for iterations and sometimes even quarters. They pile up because teams have multiple priorities to tackle and each feature can have dependencies and defects arising that take up the space of the next iteration. When this happens, relevant priority comes to play.

Is the priority discussed with stakeholders two quarters ago still relevant to the business, as opposed to the new priority? Is the question agile stakeholders, agile product owners and agile teams should ask themselves to answer the question; Is it relevant?

The Relevance Shift

A real world problem of relevant priority

---

We had just launched our minimum viable product (MVP) of the social trading application and celebrations were in order, Yay!

Our sales and marketing team, along with one of the owners, had prioritised the need for multiple promotional banners to promote the application and exclusive offers and competitions involving trading. Using technologies such as Elastic, we load tested the MVP on a a higher request scale that would accommodate the estimated traffic caused by the planned campaigns. The test results showed broken functionalities, with some defects being highly critical as they effected the user’s portfolio. Unfortunately, during development of the MVP, the team changed significantly, and this effected the technology integrated and the overall infrastructure of the project.

The beginning of the priority extension

The team had by then realised that some technical debt had not been paid. Part of the current architecture had to be revisited and code refactored. With other priorities in line for the team to work on, resolving technical debt took the team 5 sprints. Almost the whole quarter. Such incident delayed any promotions and campaigns of the product by 2 quarters.

The business change

As the team worked on resolving technical debt, owners adapted to new business priorities. The introduction of white-labelling the product itself to prospective clients that wanted to enter the industry of trading.

Change in priority relevance

Without proper load balancing and communication channels, there would be no promotion of the app. After all, no one business would want to see their app break down during a hot campaign due to high volume traffic.

The problem, however, was that the business had shifted towards white-labelling the product and the deadline was only two iterations. The need of a fully functioning application still maintained its highest priority because we had no control over how far the white-label client would go with promotion. However, due to the shift in business, without a white-label to offer there would have been no white-label client and therefore the high priority load balancing stories lost there relevance without losing their priority. For the business that had now shifted its focus on white-labelling the product, handling a large number of requests on the app became irrelevant given that there is no white-label product to scale test.

Tackling priority relevance

That was how we tackled priorities that otherwise would create longer discussion, confusion and disruption to teams. In order to understand priority, scrum teams can work independently from the rest. Yet, to understand and measure relevance, all involved parties have to be addressed. In the above scenario, the owners communicated the business shift, which caused the shift in relevance of priorities. Similar scenarios happen often in mid to large companies.

#1 User Focused

The business success is a measure of user’s satisfaction and user’s action favourable to the business. it is important for the entire Agile team to keep their efforts user focused and user stories help teams do just that.

#2 Continuous Delivery

Because user stories are small pieces from a feature, the effort involved is always achievable within one iteration. This promotes an un interrupted delivery of new system behaviour

Final Words

---

Writing user stories is an art that requires practice and experience. A good user story is one that describes the piece of functionality required, meets all its acceptance criteria, can be achieved in one iteration and resolves partially or completely one of the relevant priorities.

Let’s now hear it from you. What’s your user story? Drop a comment below!

---

Frequently Asked Questions

---