Six Dimensions for Decomposing Stories

Many teams struggle to break down stories to a size that can be completed within a sprint. Perhaps the product needs seem too large, or the technical debt is too deep. There could be a high degree of uncertainty around what the product should be. Or, the team might be new to the domain. Regardless of the reason, here are a few ways we tackle this in the dojo - and given that we generally do two-and-a-half-day sprints in the Dojo it’s critical that teams develop this skill.

Here are six dimensions to think about when decomposing stories.

CONTEXT

Many teams lack big picture understanding for products they build. Instead of having deep knowledge of the problem they are trying to solve, they are equipped only with a backlog of things to do. In these situations, it’s difficult to find meaningful decompositions of the work. Take a simple example - a need to filter a search result. Without context of how customers actually use the product, teams resort to building filtering capabilities for every element in the search result. Even if they have ideas around building filtering incrementally it’s hard for them to make decisions on what to build first without product context.

In the dojo, we focus on building product context for teams - not just around what they are building, but also why they are building it and who they are building it for. We use product chartering, personas, and story maps to ensure everyone has a shared understanding of the problem space. Teams are able to break down stories more easily when they have product context. Back to the search example – when teams have product context they’re able to say “this filter is important in the context of the search we’re implementing for this persona right now.”

COMPLEXITY

Products can be complicated to build. Some products require integrations with large datasets or other systems that have less than ideal APIs or interfaces. Or, an innovative product idea that could make a user's life better may be very complex to implement.

Development efforts like this naturally take time. They are ripe for errors when estimating the work effort because there are so many unknowns. Knowledge is created quickly in these spaces as a result of all the learning that occurs during development. It’s difficult to estimate the effort and time required for this learning.

When working with teams in the dojo on these types of problems we look for paths of increasing complexity. We start with simple, obvious cases. Sometimes teams will push back and insist we’re starting too simply. (We often hear a similar objection when teaching test-driven development and we’re giving guidance on creating the first test.) Teams often over-estimate their ability to handle complexity.

For that great search feature, we will start with a direct match before we work towards more complex criteria. Later, after we have learned more about the tech and the product, the team might graduate to working on fuzzy logic.

Teams learn as they go and move gradually into more and more complex scenarios.

EXAMPLES

Using examples is our favorite technique and quite possibly the simplest. It’s sort of “Team Test-Driven Product Development”. Teams could even call it building against test cases.

When a team encounters a large story in the dojo we have them talk about the story before trying to break it down. We ask them to come up with examples of what the product would look like if the story was completed - both positive (working) and negative (failure or error) examples. From there, the team chooses an example that is interesting to them. We encourage teams to choose an example that will help them learn something by asking open-ended questions such as - Will this example help us learn about integrations or some aspect of the technology stack? Will it help us validate a product idea? Will it help us improve the way we work (e.g., will it force us to implement new automation techniques in the testing space)?

Using examples is a nice, easy way to frame discussions that helps teams make progress on decomposing stories.

STUBS

Many teams in the dojo are building products that are dependent on outside influences - other teams, external APIs, or other products. Often these external dependencies influence teams into thinking one or more of their stories cannot be decomposed, and even worse – delivering their product is outside of their control.

When this happens, we talk about expected behaviors and contracts for tests. What do we expect the dependencies to return in each of the examples? How should the product behave? We help the team learn how to isolate their product in a way that enables testing and allows the team to make progress delivering. For legacy code, or systems where it’s difficult to drop in stubs or mock data, we have teams use tools like WireMock to provide some of this isolation and control.

But it all starts with that conversation around expectations and behaviors.

Be careful with this approach. Teams can get “isolation happy” and eventually find themselves actually deferring product integrations - which is a bad thing that can easily lead to over-accumulating work in progress.

SPIKES

Teams are sometimes working in unchartered waters. This could take on the form of new technology, unfamiliar legacy code bases, or learning something new like cloud technologies or microservices.

In these situations, teams sometimes fall into the trap of over-researching. When trying to deploy to the cloud for the first time, teams may read documentation and blogs, watch videos, and go through training materials for weeks to understand all of the options with the hope of “doing it right the first time.”

“Spiking” on stories is a common technique teams have been using for years. Again – there are traps and pitfalls. The worse being spikes with no clear end-game, even when they’re time-boxed. For example, when would a spike around “Learn how to deploy to the cloud” be finished?

In the dojo, we frame spikes contextually around answering a question. Instead of creating a spike to “learn cloud deployment” we might ask “can we move an already built jar file from Artifactory to an AWS EC2 instance?” By phrasing it as a specific question, the spike has focus and context and becomes a nice starting place for sharing learnings and demoing results.

INVESTMENT

There are times when teams try all of the above and still struggle to decompose a story to a size they can complete within a sprint. They have context, they have broken it down across a test boundary with good isolation, and so on. But the work is still “too big”.

Another approach we’ll use is to have teams talk about the investment required to complete that part of the product. We start with simple questions - How much would be too much to invest in this? How do we know? Similarly, after we have finished a story, we often ask the teams if they’ve learned anything that causes them to question the value in continuing the work. Should we keep investing in this line of product development? Should we pivot? If the overall product direction is still valid - Have we learned anything that might help us think of a different route for delivering the product?

The above approaches have worked for us, what has worked for you?

A Better Center of Excellence

Many organizations attempt to manage knowledge by creating Centers of Excellence (CoE). A CoE is supposed to develop skills and best practices (or leading practices), codify the knowledge around those skills and practices, and blast that knowledge out to the rest of the organization. In our experience, CoEs seldom work. They do not deliver on the expected outcomes and are eventually abandoned.  

Dojos can deliver on the intent of centers of excellence. Let's look at CoEs, how they typically struggle, and how dojos address these issues.

Spreading Knowledge

The idea behind CoEs is that once we have a core group of people with 'the knowledge', they can simply 'go forth and deliver the knowledge.' As Dion referenced in our recent webinar, knowledge is very difficult to codify and externalize.

Instead of trying to package up knowledge and hand it off to teams, Dojos amplify knowledge creation through frequent application of new skills with teams. This application of new skills is not only done in the context of their daily work, making it stickier, but also in a safe environment with coaching support. Instead of trying to codify knowledge and pass it from person to person, dojos create learning experiences where participants have the opportunity to create knowledge for themselves.

Separating Centers of Excellence by Skill

Many CoEs fall into the trap of creating separate centers for each skill or practice area. Perhaps one for testing, another for micro services, another for cloud native architecture. While this does seem to make sense - get the best people with the most knowledge around a practice area together - it neglects how the different practices work together cohesively and how you tie the practice areas together.

Dojos solve this problem by not focusing on skills or practices in isolation but rather in the context of the end-to-end product development lifecycle. Dojos take into account how the various skills and practices influence each other. Coaches work with full-stack teams to provide broader perspectives and deeper knowledge creation across different skill sets.

Creating Internal Best Practices

The core tenet behind CoEs is to find and promote best practices. This is problematic in and of itself since we know best practices work only for the simplest, most obvious problem domains. In addition, this is usually attempted through recruiting a small set of people that have been successful in their roles and bringing them all occasionally together to try and create patterns.  The onus is on the small group, a centralizing control. For those readers familiar with "The Starfish and the Spider", this is definitely a spider model.

The dojo, in contrast, is a starfish model. Instead of centralizing knowledge, we are trying to help teams grow their skills and then give back and share with others, removing the central ownership of ideas.

Dojos are the best way to achieve the intended outcomes of CoEs.  Want to learn more?  Reach out to us and let's chat - hello@dojoandco.com

Annealing and Tempering Product Teams

Annealing and tempering are two complementary heat treatment processes used to alter the physical characteristics of a material, most often metal. They’re frequently used to increase the strength of the metal while ensuring it does not become brittle. Like annealing and tempering – the learning processes that take place in the Dojo make product teams stronger while reducing their brittleness.

But first, some grounding…                                                

What is a “Product Team”?

 A product team is a group of people working together to deliver a product. Collectively, they have all the perspectives and skills necessary to develop the product.

The team has deep customer knowledge. They have a shared understanding of the customer’s desires and their underlying needs.

They understand the product opportunity as well as the development costs, allowing them to make informed design and delivery decisions about their product.

Their skills are not limited to development. They are also able to validate ideas in the early stages of product discovery, frame the product development effort in a way that supports fast feedback loops for learning and adjusting, deploy and run the product in production, and make adjustments based on analytics and feedback from real customers.

How does the Dojo help?

 First, the Dojo helps organizations understand how to form product teams. Resilient teams don’t spend weeks spinning around product feature decisions or struggle for long periods of time under the weight of not understanding their technology. It’s common to restructure teams during the intake process before they even enter the Dojo, ensuring all the skills necessary to complete product development are represented.

Product teams strengthen their skills by focusing on learning. All learning in the Dojo is done in the context of real product development, but learning is prioritized over delivery. And learning together – in pairs, small groups, and as a full-team – strengthens skills better than individual training.

A distinct advantage Dojos have over traditional courses is that teams improve all of the skills encompassing the full product development lifecycle. No more piecemeal training that doesn’t stick because teams don’t understand how it fits into the bigger picture. Or worse yet, training that doesn’t stick because it’s incompatible with the rest of the development cycle.

Product teams develop self-awareness by going through a Dojo experience together. They gain an understanding of each other’s strengths and skills and know how to best employ them collectively to optimize product development.

Would you like to have strong product development teams? If so, the Dojo will help you get there.