Paradigm shift: Slicing Features

Adventures in slicing features.

Teams need to learn the artful skill of slicing features into stories a related to their business context and domain purpose. A typical anti-pattern is for teams to waterfall their iterations, as described in the next two scenarios.

The first iteration we will gather all the requirements, the second iteration we will design, the third and fourth iterations we will build, and the fifth iteration we will test…and so on…

This is an inter-waterfall anti-pattern. It is essentially a pure waterfall approach chopped up into smaller time boxes.

Another derivation of this anti-pattern is to order up another form of phony business agility and/or Scrum.

In this iteration we will pull “requirements gathering” stories first. When those are all finished, we will pull the “design stories”, and then “build” stories…

In this case, it is an intra-waterfall anti-pattern.

The next common anti-pattern related to intra-waterfall is for dev team members to pull stories and work on them independently. This is a siloing ant-pattern, indicating the team is not cross-functional and is simply a collection of silos and individual waterfalls.

These are some common ways to address these anti-patterns.

  1. re-organize the team to become more cross-functional and aligned to a domain purpose.
  2. re-evaluate your feature and story slicing paradigms to ensure that the PO and/or team is not driving waterfall into the structure of the ways of working and work itself by organizing the work/effort into waterfall-like parts.
  3. the Scrum master should teach the team to slice features into stories that may be worked by a slice of the dev team, thus avoiding the intra-team-silo pattern, enhancing collaboration, and enabling flow

how-to move past the anti-patterns

An example of learning a feature slicing pattern follows.

Backlog refinement for a feature development team (not a component team):

PO: I am hungry. I want to eat bread. So that I will have nourishment and no longer be hungry.

Iteration 1:

Dev Team: here you go…this is what we did for two weeks.


PO: I can’t eat that! I think it is only the ingredients! I’m not even really sure what all of that stuff is, I’m not a baker (technical/functional expert), I just want to eat bread!

Dev Team: We only had time to collect the components for bread! All of the components are good and safe! You can eat them! Eventually, we will put them all together into bread.

SM: <face palm>. Team, we can’t just deliver the components. We must deliver the bread in a form that the PO can eat. We need to learn how to slice this feature into a form that the team can deliver each iteration. Delivery of non-working components is not compliant with the value system and principles that we agreed to. We should also begin to document our definition of done, so that the next time we are feeding the PO we remember to not deliver just the components. So, what part of the feature, that is working, can we deliver next iteration?

PO: I’m still hungry!!

Dev Team: OK, we appreciate the feedback and will work on delivering working bread next iteration.

Iteration 2:

Dev Team: here is our Team Demo, Miss PO! Check it out! Risen bread!


PO: Well, that at least looks sort of like bread now. But, it doesn’t look cooked! I don’t want to get sick eating un-cooked bread. I cannot accept this. I was really hoping to make a bologna sandwich with slices from the loaf of bread.

SM: Team, I think we are exploring new acceptance criteria for the feature, and learning more details about what the product really is. Lunch.

Dev Team: Oh, you want a sandwich for lunch! Now we understand! If we knew this, in the beginning, we would have helped the PO slice the stories for the feature in a completely different way. Also, it seems like we may need to re-write the feature to be more descriptive than just “I am hungry, I want to eat bread.” It also appears that we don’t have the domain expertise to complete the product. Our domain purpose is baking bread and so we usually work on features within our domain. We will need to talk to one of the other teams that specialize in bologna about our dependency.

PO: Wait, I also want lettuce, tomato, mayonnaise, and mustard on my sandwich!

Dev Team: <face palm> Wait, what? Why are you just telling us this now? Now we will need to talk to the condiments team too!

PO: Well, until I saw what the bread looked like I didn’t realize that I would need all of those other things.

SM: That is an interesting turn of events team! Let’s do some more refinement and practice elicitation of the requirements with the Product Owner. Then we will write some new stories, maybe even some spikes and I’ll schedule a few hacking sessions.

Iteration 3:

Dev Team: Hello everyone, we are really excited about the Team Demo this iteration! We believe we have a working feature! Check it out, a cooked loaf of bread:


PO: Well, that looks really tasty! But, it is still not a sandwich. I want to eat bread as part of a bologna sandwich, for lunch.

Dev Team: Well, we are a feature development team that has a domain purpose of baking bread, we are bakers, not sandwich makers!

PO: Well, even still why isn’t the loaf of bread sliced? We can’t deliver a loaf to make a sandwich, we need to deliver two slices of bread! The product management team is not going to be happy! It has been 6 weeks and we still are not able to deliver our part of the product.

SM: Team, I think we have an integration and dependency problem. Also, we should rethink our team’s domain purpose because I feel that we have the skills necessary to create and deliver this sandwich from the component parts. We only need to collaborate with the other teams to coordinate our efforts so that the team has time to integrate the various components. Our feature is really one of the critical components that we must build since the company uses an outside supplier to buy bulk bologna.

PO: Yes, that’s true we get most of our bologna from Sutherland Meat Distributors and we buy some pre-sliced bologna from the PMI Meat Market. We only have to slice the bulk bologna it into sandwich meat sized parts. The PMI bologna is ready to use in our sandwiches, but the quality is not near as good compared to the Sutherland bologna. Some of the product managers even joke about how the PMI bologna may contain 98% afterthoughts rather than actual choice cuts in the sausage.

Dev Team: Haha, funny. We did talk to the other teams and they told us they would get the baloney and condiments ready. But when we asked them yesterday afternoon where the baloney and condiments were they said we never came back to them to get the parts. So, we didn’t have time to make a sandwich. Our capacity was tapped out!

SM: Have you guys heard of Lead Time and Takt Time? I think some Lean concepts will really help our Scrum team. Also, we will need to find a better way to coordinate the efforts of the other teams. Lastly, for now, we need to create a way to visualize all of our efforts since making a bologna sandwich for lunch involves so many different teams and suppliers. But, enough of that. I think I recognize a core problem in how we should slice our features. We keep focusing on delivering the entire loaf of bread when we really should be focused on delivering the two slices as early as possible, in edible form. Then the team would have time to integrate the bologna and condiments into the final product. In fact, we have the sandwich bar team that has a unique domain purpose of helping the bakers integrate the components. They also support our ovens, keep the knives sharp, and clean up the machinery and bowls each day. We could bring them in on the collaboration so we can coordinate all of our efforts seamlessly.

What do you guys think about mapping out our process so that we can determine if we have a systemic bottleneck or portion in our work process that would keep the team from baking just the two slices and delivering them in the first iteration?

Dev Team: Yes! If we organize our ingredients into smaller batches and create a mold for bread slices we could easily rework our process to produce the bread slices much more quickly and at a higher quality since we can control the process with the smaller batches more effectively!

PO: Awesome, team! I would be willing to discuss how the slices would look, taste, and what shape they would come in so that we can all learn from the feedback. And since we would be able to deliver slices faster we could work on managing the queue of requests for more lunches and enable an ability to manage our capacity!

Ideas on how to improve

A cross-functional team slicing features into cross-functional stories is a more desirable pattern as it enhances team collaboration and promotes XP practices

Cross-functional teams are a requirement if you want to claim Lean-Agile-Scrum practices are in play. Otherwise, the team is just a silo of specialized resources. Silos create waste through handoffs, holding costs, and dependencies while increasing Lead Time and Takt Time.

Decomposing or slicing features into cross-functional stories is a more desirable pattern than functional stories. Functional stories tend to support the anti-patterns of intra or inter waterfall behavior in iterative development teams.

How teams slice features will have a direct impact on capacity, flow, and quality.

Stories should be sliced to a normalized “smaller” or “sized-appropriately” size of the effort, complexity, known/unknowns to enable Lean concepts of smaller batch sizes and ability to manage queue lengths more effectively.

Components and Integration

Integrated product:



Published by Marshall Guillory -

Information Technology professional, transformation leader, agile evangelist & coach, change agent, scrum master, servant leader and more...

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: