7 Common Mistakes Splitting Stories
Whether you are working on a product or a project, you must find ways to progress from the big idea down into something that is achievable within your defined constraints. The purpose of the user story is to meet the needs of the user. By design, it is a means of communication between the stakeholders and the engineering team to ensure the dissemination of desired outcomes to the everyone. Whoever is accountable for facilitating this conversation will need to break down these ideas into buildable chunks of work. Here are some of the most common mistakes made when splitting stories.
Mistake #1 Splitting Stories Upfront
Understanding that a living and breathing product is never finished, while a project is a temporary entity that has an ending. Both find ways to build out your idea, so organizations need to finds ways to deliver the most value within their constraints. You must prioritize the things that you need to get done. You can create something that people desire to use or consume in some way. There could be some “nice to have’s or exciters” that need to wait for various reasons. The pressure of getting it right drives people crazy. There is always the possibility of missing something in the requirement. Some people will address this fear by splitting stories every single detail upfront.
Complexity drives another fear that can throw people into a panic. As complexity increases the robustness of the solution may need to increase as well, which triggers the fear of missing something. The counter is to know all the requirements up front so that one can plan for all possibilities in the architecture. You can expect this natural fight or flight response from people. Understanding that architecture emerges leads to the fact that complexity requires feedback over time. We typically divide hard things into smaller more manageable pieces, which lessens the need to know everything on Day 1.
There are times when too much information can stunt innovation or the critical conversation. It gives the appearance that there are no assumptions and there are no more questions. The entire team is not encouraged to look at problems and possible solutions in different ways from various perspectives. It becomes merely a checklist. An extensive list can lead to adding more details than necessary, which will lead to longer development cycle along with longer feedback cycles for stakeholders. Instead of trying to break down everything, in the beginning, consider starting with the most complex or most essential requirements—then adding the remaining items over time as you learn. It will vary based on your needs.
Mistake #3: Going It Alone
Don’t forget that a requirement takes a crew of people that bring different perspectives or skillsets to construct the desired outcome. Requirements engineering is the activity of bringing perspectives together to imagine, discover and iterate to the “perfect” requirement. Even when we realize this truth, many teams are splitting stories into architectural components or engineering activities, so that one perspective can address it or dominate the conversation. i.e., the expert. The goal isn’t just to simplify design but to create small and meaningful paths, and rules, which requires input from the entire team. Ensuring that all options are explored, such as how and where splitting stories make sense. In the spirit of Agile, you get feedback on the requirement itself with the involvement of the team.
Mistake #4: Splitting Stories For The Wrong Reasons
Another common mistake made when trying to create a series of smaller stories is splitting stories for wrong reasons opposed to vertical slicing for user function. The fact of the matter is, some stories will be larger and more complex—with a full technology stack to deliver the desired feature. Per its name, a user story is all about the user and their goals. When split based on engineering tasks or technical boundaries, you can leave value and function on the table.
Remember splitting stories along user paths is one easy way of minimizing the temptation to divide stories for technical boundaries. Some splits will be easy to carve out, i.e., the payment and checkout functions. It might include the ability to ship to the same address every time or to a different address, or to pay with multiple payment options—such as a using a $50 gift card code and the balance in a debit or credit card. Or the option to ship standard, express, or overnight. Regardless of its nature, each path should focus on achieving a user goal.
On that same note, since the goal may be to test a minimum viable product, you find many high-level stories or epics—but only put a few of these together to garner some feedback. For example, you may not initially offer overnight shipping or the option to pay with gift cards. It simplifies the initial outputs, and the additional paths can be added further along in the Product Backlog.
Mistake #5 Story Assumptions
Communication is critical, so assumptions must not be made or at least verified. A team that assumes all the options will be doomed to MOUNTAINS of RE-WORK. Technology is continually evolving along with ever-changing desires of the user, which means that even standard paths will evolve too.
The key is to focus more on the “what” than the “how” when creating the user stories. For example, maybe this client will only accept cryptocurrency or PayPal as payment and not debit or credit cards. Instead of assuming how in the user story, keep it short and simple “user processes payment.” Yes, the team will eventually need to define the payment options. Too much time is wasted creating this level of detail that may not be necessary until we are closer to working on it.
Remember, user stories are the talking points of the overall goal. If there are too many specifics, there may be too many splits.
Mistake #6 Over Or Underusing Spikes
An essential part of gathering information is performing the additional research required to deliver innovation. Spikes are research activities designed to perform the investigative research the team needs to complete, define, simplify, or create a meaningful user story. Each Spike is a timeboxed event. Once the time is up, the team reaches a decision. Sometimes the decision is to invest more time in research. While more time may be required, try to keep the add-ons to a minimum by taking a strategic and measurable approach to research.
The most common reason for adding too many spikes is out of fear of getting the estimate or projection wrong. The entire team must pull together and work together as one, empowering one another to do what they do best. They classify each mistake as a learning experience. Living and breathing Agile leads to self-organization and team accountability, void of the common pressures of top-down project management. When teams are comfortable and confident, it will lead to spikes used as needed.
While too many spikes could cause a delay, too few will sacrifice quality. A few ways of determining if a spike is required is to consider: 1. new or unfamiliar technology. 2. A new innovative solution. 3. The story is too large or complex. Use Spikes to clarify the user’s goal. It will remove unclear definition and reduce uncertainty to save time and money. Don’t use Spikes for common or regular stories. It will overcomplicate the process.
Mistake #7: Implementing All Rules From The Start
Every organization has a list of company and industry rules, regulations or industry-compliance. Let’s call them Business Rules, which impact every relevant user story. Organizations follow Business Rules for a reason. They fall into two main categories: business operation and system imposed. Even if this makes things a bit more time consuming, they are required. Depending on the scenario or user story, rule postponement is possible. Take a look at one-off situations or rare and uncommon paths. Might be a right place for a “fill in the blank” story.
When this occurs, the rule may need to be temporarily removed, relaxed or split. It can only occur if the feature does not violate business or compliance rules, or if it the Sprint will be “complete” without the feature is fully functional. For example, complete by 50 percent in this Sprint and 50 percent in the next Sprint—or by 25 percent over the next four Sprints. While this is not an actual split of a story, it is splitting stories based on the work required to complete the story.
Consider an app that allows users to order prescriptions online. The organization requires prescription verification and customer identification. The solution requires many different and complex paths. You can achieve full compliance by breaking this into a few different Sprints. The release will need to wait in some cases to get compliance.
Remember splitting stories takes a bit of art and liberty, so it is virtually impossible to make a perfect user story. Even veteran writers have to get back to the basics sometimes, so there is always room for improvement. These common mistakes can be impossible to catch all the time, but this is just a starting point.
This article is Part 2 of 6. Next up, more on why you need to split your stories.
Don’t forget part 1 – User Story – Start With Training Wheels