PremierAgile

Agile organizations have expanded in the various markets where several companies use the Agile Methodology for product development and delivery. Companies always look for candidates who are updating themselves concerning the situations and learning all the basic knowledge about the Agile Methodology. One of the most important parts of Agile is knowing thoroughly about User Stories, the concepts behind it, and ways of writing the User Story. All members of the Agile team should understand the importance of User Stories, and learn the skills to write the best User Stories that justify the customer's needs. When all the members understand the User Story, it becomes easier for the team to work during the Sprint. Hence, knowledge of User Stories and knowing how to split User Stories are a few of the critical skills and techniques that every professional in the Agile team has to know. 

In product management and software development, a User Story is the natural language description that is informal and has one or more features of the software system. The User Story acts as a tool in Agile software development to clearly understand a software feature from an end users perspective. It helps the developers to understand the type of user, what they want from the software, and why. Hence, a User Story creates a simplified description of the required feature. User Stories are recorded on index cards, on Post-it notes, or in project management software. User Stories can be written by various Stakeholders such as Users, Managers, Clients, or Developer members, etc depending on the type of project on which the Agile team is working on. User Stories are parts of the Agile approach which helps the team to focus from writing about the requirements to speaking about them. All Agile User Stories have a feature of being written in a sentence or two and more importantly, the User Story functions as a series of conversations about the desired functionality.

Why are User Stories important in Agile projects?

Whenever a new product has to be designed the requirements of the product change periodically according to the feedback of the customer, market trends, and several other factors. The teams and customers learn more about the system as the project progresses. Hence, it would not be realistic to make the project teams work on all the planning and static requirements list before the development of the product. It would also take months to plan and when the product has to be developed, the market trends may change. At this time, the User Story approach of Agile is used where the big upfront design is replaced with a just enough approach. One of the important reasons why User Stories are essential is that User Stories reduce the time spent on writing exhaustive documentation as it focuses on the customer-centric conversation. User Stories help the Agile teams to deliver quality software quickly and make the customer satisfied with the product.

Few of the benefits of adopting a User Story approach in Agile development are:

• Capturing and prioritizing requirements is easier and saves time as the format is simple and consistent. Also, the process remains versatile enough to be used on small and large features. 
• Delivering the product that the client needs will increase the product and the business value drastically. 
• When too much detail is introduced in the beginning, it prevents the options for new designs and forces the developers to think in only one direction. Using the approach of User Stories avoids this situation and promotes creativity among the Agile team.
• Negotiation and movement can be invited when small enough chunks of User Stories are present
• Assigning the technical functions to their experts in those areas such as architects, developers, and testers, and so on. 

What are some powerful ways to split User Stories?

User Stories sometimes become complicated for the developers to understand fully or a particular User Story can consist of many factors that have to be worked on so that the User Story is considered as completed. Hence, it becomes an important task to simplify the User Story by splitting it into smaller and simplified User Stories such that the developers work on it efficiently and the product delivered is exactly what the customer expected. 

One of the interesting and helpful ways where User Stories can be split into lightweight stories that are easier and effective is the SPIDR method. Mike Cohn, an Agile Coach and the co-founder of the Scrum Alliance noted that almost every story can be split with one of the five techniques under the acronym SPIDR.

Before understanding these techniques, we have to understand that there are two types of User Stories that vary fundamentally from each other. They are:

• Compound User Stories that consist of several smaller stories that could be split. 
• User Stories that are extremely large from the ground up and cannot be split. It is important to note that these kinds of User Stories are extremely rare and occur only in a few product development processes.

Hence, we discuss the five different techniques to split compound User Stories.

Splitting compound User Stories

The INVEST principle suggests that a User Story should be designed appropriately such that it must be small enough  or have the right size and should be sufficiently small such that 6-10 of them could be completed in a specific Sprint. This may vary with the speed of the Developer and to achieve this goal, a large User Story should be split accordingly. This could be achieved by using Mike Cohn's techniques which are proven to be easier, simple, and fast than any other technique. 

The five powerful ways of splitting a User Story are:

• Spikes
• Paths
• Interface
• Data
• Rules

Spikes

Spike is one of the essential terms that is frequently used in Agile software development. Spikes are defined as small, prototypical implementations of functionality which is essentially used for the feasibility and evaluation of new technologies. The Spike method includes building knowledge and several investigations. This method is often used only when other methods of the SPIDR methods have not performed as expected. As an individual gains more knowledge about the product and starts to investigate more about the various factors influencing the Product Increment, some stories can be better understood and possibly could be split very easily. The Spike method is considered to be relatively abstract and hence is harder to apply when compared to the other methods. 

Paths

Whenever a User Story has several alternative paths, one of the choices for the professional is to make separate User Stories from these paths. User Story for each path is not necessary to be written, however, the professional can write most of the alternatives where it makes sense. Let us take an example of a grocery store that functions online. A User Story is written where the user wants to pay for the purchases online. There are several possible paths for the payment as the customer can pay with a credit card, debit card, PayPal, or through internet banking. The payment with internet banking may have several other subdivisions such as the different types of banks offering internet banking services. Now it is up to the developer to understand whether it would make sense to have a smaller story for all the subdivisions. However, the task of designing the payment for the online grocery store is subdivided into smaller User Stories based on the alternative paths of the initial User Story. Hence, the newly created smaller stories are simple and easier to estimate. 

Interface

In the context of Project Management, interfaces could be an example for different devices such as smartphones which are powered by android or iOS. Using this interface, User Stories could be split into many smaller stories. If we use the example of different operating systems, in a project, for example, there are User Stories that may apply to all types of devices such as web browsers, Android devices, etc. Hence, to avoid making User Stories long and comprehensive, it should be decided initially about the type of interface that the product is working on. This could be achieved by splitting the User Story based on the type of the operating system for example designing the product exclusively for android devices. Hence, before starting to develop the product, the device on which the product is to be developed should be decided and a User Story exclusively for that device can be written.

Data

When the initial stories refer to only a sub-range of relevant data, this technique could be used to split the User Story. Let us consider an example of a website that is intended to attract tourists to a particular place. If the place is known for all the beaches and resorts, the first story can include all the beaches in the area, and a subsequent story could include all the resorts that are available in that particular area. Also, other stories could include outdoor activities, other places that are famous in the city such as monuments, hotels, etc. Hence, the User Story developed based on the relevant data of the website that has to be created. 

Rules

Another splitting factor for User Stories could be the technological standards and business rules. If we take the example of the online purchase of any concert tickets or cinema tickets, there are several constraints based on the requirements of the respective business. One such constraint could be the limit of a maximum of six tickets per e-mail address. Initially, the Developer could exclude this restriction, which allows the visitor to buy tickets as much as they wish. However, the restriction could be introduced in the next iteration step. This process is called incremental development where the initial stories do not contain complete information, but the stories are delivered in several smaller steps and implemented incrementally. Sometimes, neglecting the technical specifications while developing the User Story can build the product faster, and could give the customer an idea of the product with faster delivery. The omitted stories could be added in the next step to enhance the product value. 

Conclusion

Smaller User Stories have an easier realization and have always made the work of the Developer simple. User Story splitting may seem difficult which leaves many beginners to leave their stories in an overly comprehensive manner which is too big. When these stories come for refinement with the Developer and implementation of stories, there is a need that these User Stories are simplified and easier to be completed. Good User Stories should always be estimable and small and using these five techniques any professional can make a large compound User Story into a small and estimable User Story that the Developer can easily complete. As the professional practices splitting and diving User Stories and writing them, the practice makes it perfect. Hence, learning the skill of splitting large User Stories can benefit everyone on the Agile team, the customers, and ultimately the organization.

References

1. https://www.scrum.org/resources/blog/user-stories-are-needs-described-business-perspective
2. https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story
3. https://www.scrum.org/forum/scrum-forum/27050/techniques-splitting-user-stories

Useful Links:

Agile Estimation Techniques, Certified Scrum Master Certification Course Toledo, Advanced Scrum Master Course Training Santa Clara, CSM Course Dallas, A-CSPO Online Training Kochi, A-CSPO Course Training Dhaka, Advanced Certified Product Owner Course El Paso, Advanced Certified Scrum Master Certification Course Little Rock, Leading SAFe Course Training Durham, Product Owner Characteristics