Getting started with the day’s work as you take a look at the software requirements, you may end up interpreting the requirements in several versions. Scratching your head, you wonder which one is correct. This is a typical scenario that circles around the technical team in a traditional waterfall-oriented process. This results due to the disappearance of the customer right after providing the requirements in 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 that involve user Stories i.e., seeking active involvement of the user will always bring a different feel and rhythm than those using the routine process. In a tradition process, 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 kind of processes, the role of customer diminishes after he provides the requirements. And he re-appears only after you complete the project, on the basis of your understanding of the requirements.

You would agree that this just cannot work well. The top merit of user stories, thus, is the active involvement and presence of the users throughout the duration of 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 on 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 that how much time they would require to complete each iteration.

This estimation on the speed of delivery by the development team is termed as Velocity. Often, in a user-story oriented project, the first velocity, as defined by the technical team, is likely to be wrong since the assessment is done without any 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 are also estimated.

What Exactly is a User Story?

A user story is a brief description of a feature which is defined or specified by the customer in the simplest terms. The user has a prime objective of attaining new capability of the system. The requirements of the user are focused completely on what the customer wants to have and not what the user wants the system to do.

Who Write the Stories?

Writing user stories involves a workshop where the user and his team brainstorm to an extent that they churn 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 of a travel reservation website. Here, the various type of users could be frequent fliers, vacation planners, and so on.

Some important facts and benefits on user stories, as described by moutaingoatsoftware, are as follows:

1.Problem that User Stories Resolve – In projects, communication is one key problem. So, it becomes imperative for ensuring communication between the one who wants the software and the one who builds it. User story resolves this communication issue.

2.Balance is Vital – An important 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 suffers.

3.Distribution of Resources – It is important to address problems pertaining to resource allocation. A project depends heavily on proper distribution of resources. Any side that suffers a dearth is likely to give way to problems.

4.Inadequate Timetables – It is difficult to specify a software schedule. This happens because the users keep on adding their ideas and requirements during the course of development of the software. Taking into account so many requirements, the developers face difficulty in estimating time.

Now that you understand what user stories are and why they matter so much, lets introduce you to best ways in which you can 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. The exercise of writing a good user story, thus, involves collection of as many stories as is 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). In fact, I.N.V.E.S.T. is considered as a universal standard guide for The acronym was made popular by Bill Wake’s original article from 2003.

The acronym “INVEST” can remind you that good stories are:

Independent – A story which is independent is the best to address and worked upon. Independence in stories helps in deciding or changing priorities in user stories.

Negotiable – A story is which is negotiable is always good. This is because a negotiable story allows rooms for modifications at any given point of time.

Valuable – The story should be considered valuable both by user and the technical team. Else, it cannot be considered useful.

Estimable – Even though estimating the correct or exact length of any user story is a tough task, 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 in such a manner that it can be validated at any point of time. The user or the technical team must ensure that some testing criteria is in place much before the team begins to work on it.

How Splitting Larger Stories into Smaller Slices Helps

Larger 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 the fact slice-specific targets faster and much more effectively.

Another merit of slicing down the larger user stories in smaller ones lies in the fact that it helps developers in estimating 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 in smaller units, it becomes equally convenient for a product owner or user to prioritize the requirements. Also, when sliced in the most accurate manner, smaller user stories enable the technical team to deliver fast and thereby resulting in faster feedback.

Transiting the workflows to other sprints becomes possible easy with smaller user stories and the developers are able to focus on these requirements without missing out on any crucial aspects.

Agile coach Christiaan Verwijs explains 8 strategies for splitting the user stories effectively:

Strategy 1: Splitting on Basis of 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 enhance the understanding on its ability of time evaluation also.

Strategy 2: Splitting by Business Guidelines – Business guidelines or rules govern most user storues and it can be a good idea to split the tasks on the basis of the rules.

Strategy 3: Splitting on Basis of Type of Flow – Each user story has some sort of flow in the functionality. These are either happy flows or unhappy flows. The happy flow explains how a particular functionality works. An unhappy flow, meanwhile, describes issues, objections.

Strategy 4: Splitting According to Input Preferences – There are several platforms like tablets, touchscreens which are supported by web applications It can be beneficial if you break up large items on the basis of their input options.

Strategy 5: Splitting as Per Framework – By splitting stories in accordance with 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 on Basis of Test Case – This strategy helps most in case of big user stories which are difficult to break. Here, the developer gets a chance to decide which piece of functionality is to be tested at what point of time.

Strategy 8: Splitting According to Roles – User stories mostly involve roles that are responsible for functionalities. Splitting on the basis of roles can help you clearly estimate 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 at all 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 important to figure out some ways to handle it.

In an ideal situation, the technical team finishes off all the items on its sprint backlog in every sprint. however, often this appears to be difficult, in view of a variety of reasons.

Incomplete work is an important problem that needs a potential solution. At the beginning of each sprint, the team makes an estimation of the completing time and further commits the estimated time of arrival.In situations when these commitments are not fulfilled, the user is likely to lose trust in the development team.

It is thus, very important for the development team to introspect the delays caused after-sprint in retrospective manner. This can help the team understand the shortfalls in the best possible manner and develop a framework which will help them work better.

The team, this way, also get the right opportunity to size the stories for the next time in a much better manner. the cause for the incomplete stories at the end of a sprint can also be an outcome of an unfavorable timing or a delay in identifying a specific problem in a sprint little late. There are only a few things that the team can do to manage unfinished work.

1. Moving Incomplete Stories to the Next Sprint/Iteration – The team can move the incomplete stories into the next sprint and continue working on it. this is done, when the product owner or the user considers that story as a top priority. This is usually done in a story which is close to completion, yet remains incomplete at the end of the previous sprint.

Further, those stories that are “not done” and not even started, can be moved back to the main backlog. From there, these could be prioritized and rescheduled with the rest of the backlog items.

Leaving stories incomplete is not at all a good idea. it affects the team’s flow, synergy, and makes barricades effective future planning. here, time boxing can be useful.  Time boxing 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”. In fact, the team’s velocity cannot be specified without any constant time box.

2. Splitting or Carrying the Item Forward – In certain situations, where an incomplete story approaches completion. so, the incomplete portion of the story can be moved to 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 so that each sprint gets its appropriate portion of the story estimate. this helps in counting its velocity better. Consider the example of a team that is building a typical print preview functionality via a desktop application.

Conclusion

It is crucial that the user stories are written by the customers rather than the developers. There are two causes that support this argument. First, each story 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 sequence of iterations.

Second, customer team gets the opportunity to best describe the behavior of the product. However, the technical team needs to get heavily involved in writing the acceptance criteria. Acceptance criteria is the process where the team and customer verify that all user stories have been developed in exact accordance with the user’s requirements.

Further, an important point to keep-in-mind is that splitting should not become common a practice.  If your team feels the desire to split stories too often, it could be a sign that your stories are too big and it need improvements.

If you are looking for any help on building any digital solution for better customer or employee engagement, please contact us at [email protected].