How Technical can a User-Story be to still be “End-User Centered”?
@August 14, 2023
In today’s article, we’re exploring the technical slicing of user stories, a necessary technique to streamline development and keep end-user value at the forefront of Agile projects. We’re also elaborating on the art of maintaining the balance between technical considerations and delivering a meaningful user experience.
User Stories must Provide an Inherent Value to the Project
At the heart of Agile methodologies lies the principle of delivering value to users with every Sprint or development iteration. User stories serve as the vessel for this value, encapsulating user needs, behaviors, and expectations. Each user story represents a piece of the puzzle, contributing to the larger product vision. Regardless of your situation, this mindset that every single piece of work contributes clear and measurable value must be strictly observed.
Use of Epics
In situations where a single user story is too large or complex to be directly estimated or acted upon, the concept of an "epic" (or “epic stories”) emerges. Epics are high-level containers that hold a collection of related user stories. This technique aids in grouping and managing intricate tasks by breaking them down into more manageable, actionable components. Especially when slicing a story into technical components, it is important to remember why and how each story contributes either directly to the overall project or, in this case, indirectly via the epic.
If a story is estimated too big for one sprint, it can be pushed back (sometimes, changing the order or stories changes their estimates), turned into an epic and new slices thereof are formulated that, when done amount to the desired outcome of the epic.
Note that the process is empirical and thus proves right over time (not right in every single case) but following it yields benefits. The temptation to please a person or a deadline can be quite high and phrases like “it doesn’t fit empirically but I’m sure we can get it done” or, worse, “Last time you finished a similar story in less time, I’m sure you [dev team] can do it” are not unheard of, but those are the exact situations that Scrum calls to resolve and where the Scrum Master is wise to interject with something like:
Whenever Possible, Keep the Focus on the End-User
While technical considerations are essential, the ultimate purpose of any development effort is to enhance the user experience. Throughout the slicing process, it's crucial to maintain a user-centric mindset by ensuring an answer to the question “What is the benefit for the user of the product?” By doing so, you ensure that each technical component contributes directly to improving the user's interaction with the product. If this relation is kept and a story can be performed in a single sprint, slicing is likely done properly.
Allow a quick note on over-slicing: We have not typically seen the problem of over-slicing, but keep in mind that time could be wasted by creating tiny stories with minimal value rather than one that comfortably fits a sprint. If a story takes considerably less than half a day to complete, don’t spend too much time on it. Scrum was designed to handle complex projects. It can obviously handle simple projects, too with the risk of not being optimal.
Different Options to Slice a User-Story: Horizontal vs Vertical slicing
When breaking down user stories, various strategies can be employed. One effective approach is "horizontal slicing," where different layers or aspects of a feature are developed incrementally. Alternatively, "vertical slicing" involves delivering a thin slice of a feature that is fully end-to-end functional, providing immediate user value. Both methods enable iterative development while catering to distinct project needs.
Let’s look at an example:
Consider an Epic story: “Search functionality: As a user I want to be searching for generic products or specific products by their properties such as name, category and price range”
Horizontal slicing example: Roll out one working and feature across all relevant components. e.g. "As a shopper, I want to search for generic products by name, category, and price range so that I can easily find items I'm interested in.”
Vertical slicing example: Roll out full and detailed functionality for one component. e.g. "As a tech enthusiast, I want to search for electronics products by name so that I can quickly find the gadgets I'm looking for.”
Note that a horizontal slicing is not equivalent to finishing sub-components that do not add user-value. E.g. finishing the database, then creating a backend, then hooking up the DB and the backend and finally create the frontend is not a valid slicing since the user-value is only provided in the last step. A valid vertical slicing is created the minimally needed DB and connected backend for one single part of the frontend. It’s perfectly acceptable for the first small frontend-slice to actually involve the most work, since the DB and backend components might not exist yet. The discussion between the dev-team and the PO during the sprint planning is then: We first need to create a part of the DB and the backend no matter which user-facing feature, A or B you need first on the frontend. If you choose to do A first, it costs X. If you choose to do B first, it costs Y. The total cost for A + B is should then remain approximately X + Y regardless of the order. It’s not exactly the sum because risk (e.g. ”the unknowns”) is a variable that must be accounted for in both X and Y and may be reduced or increased depending on the findings while completing the first story.
Clear and Concise: A Technical Story Should Say What is Needed, Not How it is to be Done
In the realm of technical slicing, it's crucial to articulate the "what" rather than the "how." A well-defined technical story outlines the required functionality, leaving enough room for the development team to leverage their expertise and creativity to implement the solution. For instance, consider a user story like, "As a customer, I want to see real-time stock updates for products." This succinctly communicates the desired outcome while allowing the development team to decide on the technical implementation details.
In practice, these approaches are sometimes discussed during the sprint planning resulting in two developers arguing for how it is to be done before an estimation is given while draining the meeting time. Scrum Masters: Consider that this discussion could happen as part of the sprint planning preparation when the story is formulated and the estimation accounts for the fact that the HOW is not defined yet and can be elaborated as part of the story.
When a PO Cannot Relate to the Technicality of a User-Story: Supporting the PO in Value-Driven Prioritization
There may be instances when a Product Owner (PO) encounters technical user stories that seem detached from user value. In such cases, development team (potentially with the help of the Scrum Master) must play the pivotal role of bridging the gap. By translating technical jargon into user-centric benefits, the PO gains a clearer perspective, enabling informed prioritization decisions. Consider a scenario where a technical user story involves optimizing database queries for faster search results. The development team can highlight how this enhancement translates to improved user satisfaction by reducing waiting times during product searches. In the end, if the user stories emerges from the development team, it’s also up to the dev team to sell the story’s user value to the PO (as in convince the PO), but the PO gets to have the final word on WHAT is to be done while the dev team gets to choose HOW to implement it and to estimate the user-story in order to deliver the promised goods.
The Scrum Roles and Slicing
Scrum requires a self-organized team but the roles are generally clearly assigned. In the case of slicing, all parties PO, Scrum Master and Development Team have the responsibility to keep the Scrum process going. Finger pointing and “demanding” that one party fulfills their role goes against the spirit of Scrum. Having said that, the formal roles are assigned as follows.
The Role of the PO in Slicing
The PO is responsible for the product and user stories and prioritizes them according to his product vision and roadmap. The backlog where all user stories are held is his to manage. During the sprint planning (or preferably during the preparation to the planning), the development team must object to a user-story if it cannot commit to finishing it during a single sprint [Scrum fobids this]. Thus the PO will need to slice stories or have them sliced. Presented with the slices, the PO gets to re-prioritize the individual slices and the dev team pulls as many stories from the top of the backlog (meaning sorted by priority) into a sprint as it can commit to. When it comes to technical aspects, the PO is often not the one to perform the technical slicing and it should be a team effort to create them. If no clear solution to slicing is available, the user-story is not ready and thus becomes ineligible for a sprint. If the PO insists that it is still the most valuable story, it might be advisable for the PO to insert an initial slice story at the top of the backlog doing nothing but to resolve the slicing and thereby delegating the task to the dev team.
The Role of the Scrum Master in Slicing
The role of the Scrum Master in slicing, involves facilitating and guiding the team through the process of breaking down work into manageable and deliverable increments. The Scrum Master has the role of ensuring that the slicing process aligns with Agile principles and supports the team's productivity and collaboration. A Scrum Master must assist the development team in objecting to the pulling of a story into a sprint, if he suspects that the dev team cannot realistically complete that story but the Scrum Master is not responsible for the failure of a team to heed his advice and the dev team is thus free to ignore that well-meant advice at their own risk of breaking their sprint commitment. If this happens, it should likely be discussed at the Sprint Retrospective.
The Role of the Development Team in Slicing
The development team is responsible for delivering the increment (outcome of a user-story) at the end of each sprint. Thus, if a story is too big, they must reject it as Scrum demands. Rejection can mean that the PO de-prioritizes the story or, as stated above, creates an initial slice that tasks the dev team with further slicing it into user-valuable stories.
Conclusion: Slice Stories in a Way that Retains User-Value
Technical slicing of user stories is a skill that empowers Agile teams to manage complexity, enhance collaboration, and deliver incremental value. By mastering the slicing technique, teams can strike a harmonious balance between technical proficiency and user-focused outcomes, driving projects toward success by reducing the risk along the evolution of the project. Remember, the true essence of technical slicing lies in crafting meaningful, actionable stories that resonate with end-users while seamlessly integrating technical expertise. This synergy forms the bedrock of Agile development, fostering innovation, and propelling products to new heights of excellence.