Role of User Stories in Agile Development and How to Create a Good One
Getting started with the day’s work, as you look at the software requirements, you may interpret the conditions in several versions. Then, scratching your head, you wonder which one is correct. This is a typical scenario that circles the technical team in a traditional waterfall-oriented process. This results from the customer’s disappearance right after providing the requirements at the beginning of the project.
Thankfully, you can now overcome these turmoils in your head that bother you every day, using the concept of user stories by selecting the Agile development methodology for your project.
Projects involving user stories, i.e., seeking active user involvement, will always bring a different feel and rhythm than those using the routine process. In a traditional approach, you see the user giving you a list of requirements, and then you propose a solution. After this long-tail exercise, you get started with the coding.
Often, in these kinds of processes, the role of the customer diminishes after he provides the requirements. And he re-appears only after you complete the project, based on your understanding of the requirements.
You would agree that this cannot work well. Thus, the top merit of user stories is the active involvement and presence of the users throughout the project. There is no chance that the customer would disappear when the project is in progress.
In a process involving user stories, the iteration length, ranging from one to four weeks, is decided first of all. The decision is taken by the customer and the technical team collaboratively. The iteration length remains the same for the entire project. This is done to ensure that the developers deliver fully usable code for some subset of the application at the end of each iteration.
The most interesting aspect here is that the customer remains thoroughly involved throughout the iteration—talking regularly to the technical team. This way, the customer and his team can monitor and ensure whether the project is going in the desired direction. The advantage of deciding the iteration length lies in the fact that the developers or the technical team can assess or estimate how much time they require to complete each iteration.
This estimation of the speed of delivery by the development team is termed Velocity. Often, in a user-story-oriented project, the first Velocity, as defined by the technical team, is likely wrong since the assessment is done without prior trials or experiences.
The initial estimate, however, can be well utilized to draw a raw image or release plan. At this stage, the total number of iterations is also estimated.
What Exactly is a User Story?
A user story is a brief description of a feature defined or specified by the customer in the simplest terms. The user has a prime objective of attaining the new capability of the system. The user’s requirements are entirely focused on what the customer wants to have and not what the user wants the system to do.
Who Writes the Stories?
Writing user stories involves a workshop where the user and his team brainstorm to the extent that they churn a maximum number of stories possible in a project.
While writing user stories, one has to consider and predict all types of users a system can have. One good example here could consist of a travel reservation website. Here, the various kinds of users could be frequent fliers, vacation planners, and so on.
Some important facts and benefits on user stories, as described by mountain goat software, are as follows:
- The problem that User Stories Resolve – In projects, communication is one key problem. So, it becomes imperative to ensure communication between the one who wants the software and builds it. User story resolves this communication issue.
- Balance is Vital – An essential observation in software projects is that if either of the two sides (user and the technical team) begins to dictate, the overall development and quality suffer.
- Distribution of Resources – It is essential to address problems about resource allocation. A project depends heavily on the proper distribution of resources. Any side that suffers a shortage is likely to give way to problems.
- Inadequate Timetables – It is challenging to specify a software schedule. This happens because the users keep on adding their ideas and requirements during the software development. Taking into account so many conditions, the developers face difficulty in estimating time.
Now that you understand what user stories are and why they matter let’s introduce you to the best ways to write great user stories.
How to Write Good User Stories
A user story must entail the core business value and fulfill all the requirements mentioned by the user. Thus, the exercise of writing a good user story involves the collection of as many stories as possible. The idea behind using these many stories is to ensure that nothing is missed out.
I.N.V.E.S.T. is the most widely accepted approach for writing good user stories. It stands for Independent (I), Negotiable (N), Valuable (V), Estimable (E), Small (S), And Testable (T). I.N.V.E.S.T. is considered a universal standard guide for The acronym, popular by Bill Wake’s original article from 2003.
The acronym “INVEST” can remind you that good stories are:
Independent – An independent story is the best to address and worked upon. Independence in stories helps in deciding or changing priorities in user stories.
Negotiable – A story that is negotiable is always good. This is because a negotiable story allows rooms for modifications at any given point in time.
Valuable – The story should be considered valuable both by the user and the technical team. Else, it cannot be regarded as useful.
Estimable – Even though estimating the correct or exact length of any user story is challenging, there should always be a rough measurable predictive length of a story. This helps in deciding priorities.
Small – The smaller a story is, the better it is considered since it represents the working capacities of a few persons.
Testable – A story should always be written or planned to be validated at any point in time. The user or the technical team must ensure that some testing criteria are in place before the group begins to work on it.
How Splitting Larger Stories into Smaller Slices Helps
More important stories always entail a certain amount of risk as well as complexity. It is, therefore, a great idea to split the larger stories into small units or slices. This helps the technical teams focus better on specific requirements and achieve slice-specific targets faster and more effectively.
Another merit of slicing down the more powerful user stories into smaller ones lies in the fact that it helps developers estimate the iterations better. Also, it enhances the ability to understand the core functionality and the requirements in a more effective manner.
By splitting user stories into smaller units, it becomes equally convenient for a product owner or user to prioritize the requirements. Also, when sliced most accurately, smaller user stories enable the technical team to deliver fast, resulting in faster feedback.
Transiting the workflows to other sprints becomes possible with smaller user stories, and the developers can focus on these requirements without missing out on any crucial aspects.
Agile coach Christiaan Verwijs explains eight strategies for splitting the user stories effectively:
Strategy 1: Splitting based on Workflow – Most user stories entail some workflow. In that case, the items can be divided into specific steps. By splitting a big user story, the technical team can also enhance the understanding of its ability of time evaluation.
Strategy 2: Splitting by Business Guidelines – Business guidelines or rules govern most user stories, and it can be a good idea to split the tasks based on the rules.
Strategy 3: Splitting based on Type of Flow – Each user story has some flow in the functionality. These are either happy flows or low flows. The happy flow explains how a particular functionality works. A low flow, meanwhile, describes issues, objections.
Strategy 4: Splitting According to Input Preferences – Web applications support several platforms like tablets and touchscreens. It can be beneficial if you break up large items based on their input options.
Strategy 5: Splitting as Per Framework – By splitting stories by the parameters or framework, it becomes easier to understand what kind of search parameters will be used with what functionality.
Strategy 6: Splitting by Processes – The default operations in a user story are defined as Create, Read, Update, or Deleted (commonly abbreviated as CRUD). These can be divided.
Strategy 7: Splitting based on Test Case – This strategy helps most big user stories difficult to break. Here, the developer gets a chance to decide which piece of functionality is to be tested at what point in time.
Strategy 8: Splitting According to Roles – User stories mainly involve roles that are responsible for functionalities. Splitting based on parts can help you estimate the work.
This, however, may give way to situations where developers end up with incomplete stories. They also end up without even touching some of the user stories. Though this is not a recommendable idea, there are ways to handle these in an extreme situation. Take a look at the section below.
Handling Incomplete Work at The End of a Sprint
It is common for a technical team to get a bundle of incomplete tasks towards the end of a sprint. This is more common to teams that are new to the Agile process. Though they should not make it a standard practice, it is crucial to figure out ways to handle it.
The technical team finishes off all the items on its sprint backlog in every sprint in an ideal situation. However, often this appears to be difficult, given a variety of reasons.
Incomplete work is a significant problem that needs a potential solution. At the beginning of each sprint, the team estimates the completion time and further commits the estimated arrival time. When these commitments are not fulfilled, the user is likely to lose trust in the development team.
It is, thus, essential for the development team to introspect the delays caused after-sprint in a retrospective manner. This can help the team understand the shortfalls in the best possible way and develop a framework that will help them work better.
The team, this way, also gets the right opportunity to size the stories for next time in a much better manner. The cause for the incomplete stories at the end of each sprint can also be an outcome of an unfortunate timing or a delay in identifying a specific problem in a sprint a little late. There are only a few things that the team can do to manage unfinished work.
- Moving Incomplete Stories to the Next Sprint/Iteration – The team can move the incomplete stories into the next sprint and continue working on them. This is done when the product owner or the user considers that story as a top priority. This is usually done in a close to completion story yet remains incomplete at the end of the previous sprint.
Leaving stories incomplete is not at all a good idea. It affects the team’s flow, synergy and makes barricades effective for future planning. Here, timeboxing can be helpful. Timeboxing of iterations is an important tool in helping the teams produce more estimated results within the deadlines. Also, if you constantly vary the lengths of the sprints, you have no “measuring stick.” The team’s Velocity cannot be specified without any constant time box.
- Splitting or Carrying the Item Forward – In certain situations, an incomplete story approaches completion. So, the unfinished portion of the story can be moved to the next iteration. This is done by splitting the story to separate the completed portion of the story from the remaining work.
A relevant portion of the story estimate can be split and placed in each sprint to get its appropriate portion of the story estimate. This helps in counting its Velocity better. Consider the example of a team that is building a specific print preview functionality via a desktop application.
The user stories must be written by the customers rather than the developers. Two causes support this argument. First, each level has to be written in the desired language of the business. The technical terms end up confusing the customer most of all. This makes it convenient for the user to prioritize the user stories and decide the sequence of iterations.
Second, the customer team gets the opportunity to describe the behavior of the product best. However, the technical team needs to get heavily involved in writing the acceptance criteria. Acceptance criteria are when the team and customer verify that all user stories have been developed according to the user’s requirements.
Further, an important point to keep in mind is that splitting should not become standard practice. If your team feels the desire to split stories too often, it could be a sign that your accounts are too big and need improvements.