Reading time: 11 min read
Breaking Down Backlog Items: How to Separate and Sprint Plan Complex Work
Mastering the art of simplifying complex tasks for effective agile sprint planning
Breaking Down Backlog Items: Overview
Introduction to Properly Decomposing and Splitting Complicated Backlog Items
If you’ve ever found yourself filling the role in a company of creating trackable work tasks, then you’ve encountered the problem before (or will encounter it soon). An idea is taken on an adventure through early discussions, scoping, UX review, and finally, a UI is delivered to be built. Where, or more importantly, how do you start to break it down into easy-to-understand and track work tasks that your development team can easily pick up and work on? How can we create something that a project team can easily pull into sprints and a project manager can view to see where any task is at in its life cycle? This is the importance of effectively creating not just one, but as many comprehensive user stories as required to fully flesh out the requirements into easy-to-follow work tasks. This process is referred to as “decomposing” user stories, but it is also commonly referred to as splitting or separating user stories. Ideally, this process is a thought exercise that is completed before creating any user stories so that when it is time to create them in your backlog, you can get it right the first time. However, this process can also be applicable to any product owner looking to cut through the fog of a confusing backlog with pre-existing/already made user stories that just don’t divide work into clear and simple enough tasks. In this article, I’m going to walk through the importance of undertaking this process correctly and outline some high-level “do’s” and “don’ts” when it comes to creating and/or breaking down your user stories.
How to Capture Features and Break Them Down Into Stories
At the beginning of a feature's life span, it’s no more than just an idea. Throughout early discussions, this idea will start to take shape and evolve through iterations, and as a product owner, it’s your job to ensure that this process is easily tracked through the creation of work units. Many organizations use what are called user stories to accomplish this — this guide won’t cover what a user story is, as there are many other blogs that cover this fundamental concept. It’s important to note that not every organization is built the same; whether it be size of team, scope, or practice, each team might land on a different way to track their work and create stories. Without a one-size-fits-all approach to every team's needs, there are some general guidelines to follow when creating your backlog items, and at the forefront of this process is properly decomposing the feature into different user stories.
A feature can be big or small, complicated or straightforward, and it’s important that stories capture this effectively. If your team is looking into building a simple component that displays static text for the user to gain information from, it can be achieved in a single user story. This user story will be further broken down into tasks so that the team can assign their responsibilities in creating it; for example, “FE” for front-end work, “BE” for any back-end work required, “QA”, etc.
If the feature being built is larger than just an informational block with copy in it, this is where proper story creation will be paramount. For example, a multi-step form with different authentications and verifications that occur on each step, and different sub-steps on each page all with their own requirements. It’s much more effective to take this form and split it into many different user stories, all covering a different step in the process. For example, you might want to have the first step be its own unit of work in your backlog with its own tasks, as it may have important business requirements that need to be specifically tracked for that step. Below, we’ll cover what failing to do this looks like, and why we want to avoid it.
The Consequences of Poorly Planned Work and the Benefits of Well Separated and Planned Work
What you are viewing above is the result of incorrectly or poorly planned and separated work. In our above example, we mentioned a complicated, multi-step form. In this photo, the team's product owner created a singular user story to track each and every part of the form. This work could’ve easily been broken down into 5 or 6 different user stories that would each have a set of tasks for the development team to work on, but due to poor planning and a lack of proper decomposition, the team ended up with one user story for this incredibly complicated and robust feature. On the left side is the single user story encompassing the whole form, and on the right are individual child tasks of the user story; smaller pieces of the form created by the team to break down the user story and share the workload within a medium-sized development team. The result, as can be seen above, is almost 50 tasks to break down just one story. Due to this, each task has to be more descriptive with what it’s accomplishing specifically; instead of just stating “FE” to indicate this task encompasses the front-end work of the story, the team now has to create tasks with titles such as “FE - Step 2: Payment Details” — quite a mouthful. This approach has many obvious drawbacks. To name a few:
- How can this work be effectively tracked on a project management chart? This single user story will be worked on by an entire development team for a week or more, and because it’s so large, it still won’t be completed and ready for delivery. If you were to use a traditional project management chart, the project would appear completely stagnant — not a SINGLE user story was completed in over 40 hours of work? You and your team may understand this to not be the case internally, but other stakeholders either inside or outside of your organization often rely on the accurate creation of user stories so that they can rest comfortably knowing the project is progressing according to schedule. If a client or outside business analyst were to view your team's burn over the last week of work, they’d see a large group of people failing to move a single user story across the finish line.
- The Quality Assurance team will struggle to test the entirety of one large user story if it’s delivered to them as a whole instead of broken down into pieces. This is difficult to plan around and can result in resourcing issues and delays. If your team only has one or two quality assurance testers, they might be starved of anything meaningful to test until one morning, a single push by the development team can deliver well over two days' worth of testing that must now be completed in a short crunch-time deadline.
- It becomes even more difficult to track info you might place into your tasks for your team's reference. As an example, imagine that there is a very particular business requirement that must be covered in one of the tasks that are specific to front-end functionality, so you copy this information from the appropriate stakeholder communication channel into a task that is assigned to one of the front-end developers. That developer is pulled into another project, or is otherwise away for a week, and then returns to the project and requests you to tell them where the requirement is noted. A single front-end task on one of your descriptive, 12 different user stories is simple to look through, whereas 50 different tasks become incredibly daunting to sift through searching for information. This can waste your time, and your development team's time, and can also result in missed or incorrect functionality.
- It becomes all too easy to lose track of estimates and gauge how effective the team was at estimating their work. If the user story is too large and encompasses too much complexity, the team might attach an estimate of 100+ hours of work to it. If the work ends up taking much less time, you won’t be able to pinpoint where the over-estimation occurred; likewise, if the team ended up estimating too low and it took much longer, you can’t easily discuss which section of the feature was misunderstood. The key to agile development is continuous improvement, and every step in the process should support this. Large pieces of work with unwieldy estimates of north of 100 hours don’t allow you and the team to have productive conversations and improve the accuracy of your estimates for the next sprint.
If the team had taken time to properly dissect this feature, plan accordingly, and document multiple user stories, it might end up looking something more like this:
In the above example, a single user story only encompassed a small part of the feature, i.e. the first step and what the user would hope to accomplish before pressing the continue button. As such, this user story only needed 3 tasks to deliver it successfully: a task for FE, BE, and QA work. The estimates for all of the tasks are easy to gather and simple to track, and if something is inaccurate or was poorly scoped, the issues can be fixed quickly using this size unit of work.
The Do’s and Don’ts of Planning Complex Work
Do Err on the Side of Having More User Stories as Opposed to Less
Unless your user story is akin to the example mentioned above, a very simple informational block that the user can’t interact with, you should err on the side of having more user stories representing the feature and its complexities. In some cases, it won’t be required and the work is simple enough to capture in one, but as a simple rule to follow, it’s easier to merge multiple user stories that weren’t absolutely necessary into one than it is to go through and break them down after they’re created.
Don’t Write Novel-Length User Story Requirements
As a general rule of thumb, if you ever find that the time to read for one unit of work in your board is 10+ minutes, it has become too large. Having more details benefits all parties, but decomposing a feature into user stories correctly means logically splitting it into as many units of work required, not just one. If you’ve written a user story that encompasses a large chunk of development, it becomes easy to add details to it over time as information trickles in without noticing the size the story has grown to. Take the required time to reflect on the work items you’ve created in your backlog: has one become too large to feasibly track as just one user story? If you encounter this scenario, go through the process of decomposing your feature further.
Do Talk to Your Team to Figure Out What Works Best
Not all agile development teams are made equal, and this is OK. Some teams may be bigger, smaller, more experienced, or less experienced. It’s up to you and your team to discuss and gauge what is working and what is not. If your team is finding that large complicated user stories have become a chronic issue, make the effort to break them down further. On the other hand, if your team notices that having many stories that aren’t necessary for their flow is hindering them, consider merging unnecessary stories into one comprehensive, but not bloated story. Unlocking your team's capability depends on carefully tailoring the process to what works for them.
Don’t Overcomplicate the Process
While you’re discussing with your team, it can become easy to unintentionally overcomplicate your process by introducing too many moving parts. User stories should take a complicated feature and make it easy to understand and work with — if your process is introducing more complexity than required, it might be time to discuss in the next sprint retrospective how you can simplify things.
Do Think About What Will Benefit All Stakeholders on the Project
It’s important to talk to your team to figure out what works best for them, but the development team is just one group of stakeholders involved in the project. Always keep in mind who will have their eyes on your progress, and how they’ll be gauging it. As mentioned earlier in the article, external stakeholders often rely on accurate project management charts for their peace of mind that the project is progressing on schedule, so how you decompose your features into user stories should be inclusive of this fact. Weighing the needs of your team against the needs of all stakeholders is something an experienced product owner will have no difficulty navigating over time, and it’s important to arrive at a solution that all parties feel comfortable with.
Don’t Neglect Planning
Failure to plan results in many more failures down the line. In terms of return on investment, spending just 15 minutes planning can save yourself and your team hours of headache in the future — which seems like a no-brainer when just analyzing the numbers. Even if the team is busy and the project is in crunch-time, if new work is incoming, it’s crucial that you take the necessary time to lift your head above water, take a deep breath, and correctly plan the work that’s coming down the pipeline. Future you, and your future team will be appreciative of the fact that their work was planned correctly.
Final Thoughts on Sprint Planning Complicated Work Items
Being tasked with creating user stories that are simple but comprehensive, detailed but not bloated, and easy to track while accomplishing the team's needs doesn’t have to be intimidating. Empower yourself with the knowledge and skills to excel in the art of story creation and decomposition, work with your team on your process, and continue to create stories that work for all stakeholders until you’ve reached a careful balance that unlocks your team's capabilities. Until then, refer back to this article and continue implementing each step and improving incrementally each day. Thanks for reading!