Shape Up Forum

Integrated Slice versus Scopes

Is there a difference between Slices and Scopes?
Problem at hand:
We are trying to come up with integrated slices for every project. Slices need to be deployable, integrated (frontend+backend), and bring us closer to delivering value of the Pitch.
Since it is hard for engineers to think in terms of business value, they consider delivering some tech staff to be valuable for the Pitch.
So, the process gradually evolved into this: a slice is deliverable, short, deployable, integrated, and when shipped can provide value to the user. If the project is closed and no more work is done on it, this slice is still usable and valuable to customers.
The problem, however, was not solved, since now these slices are in no way short. They feel like an MVP.
In THE BOOK:) there is a difference between slice and scopes, but it is not evident how you can manage scope of project is some of the scopes don’t fit the timeline, and it is found out only in the middle.
Scope as is does not deliver value separately from other scopes. So, until the end of the cycle, we cannot be sure whether we are on track.
So, my questions:

  • Difference between slice and scope
  • should all slices and scopes be shippable separately?
  • should all slices and scopes deliver value to end user separately?
1 Like
  1. I think of a slice as the output of a scope map that contains one or more scopes. In Chapter 12 of Ryan’s book, he shares the difference between the two:

“Scopes are more than just slices. They become the language of the project at the macro level.”

2 and 3. Yes to both, although in my mental framework I never commit to shipping a scope, only a slice that (hopefully) covers enough of the intended corresponding scope to be valuable to users.

With regard to the problem you described, scopes that “don’t fit the timeline” are probably too large and would benefit from scope hammering and/or writing smaller pitches up front. That you “found out only in the middle” … I personally think that is good experience to learn from and will help you improve future pitches/cycles.



That sounds like an agile “paper shredder” approach, where you try to break the project into parts that can be shipped separately. The whole matters. Not everything has value by itself. It’s perfectly fine if nothing is deployed during the six weeks, but at the end of the six weeks, a whole working feature now exists.


Shoot… I pictured it so differently.
OK then, when I think of it, the only valuable thing I wanted to get out of slicing is understanding whether the Project will hit the deadline.
Our team is not mature yet, both in attitude and seniority.
So it is hard for them to say whether they are on track or off track, and after 5 weeks we can learn that we are 2 years from deployment:)
With scopes/slices deployed, it is easier to evaluate the work left, do trade-offs, negotiate scope and focus on business value to be achieved.
What kind of milestones would you recommend to the teams in this case? To stress the point, I don’t want control or reporting or something, I want to help them understand where they are in the project. They really struggle with that

1 Like

Sounds like maybe the project isn’t very well shaped if there is so much doubt about whether it will get finished during the cycle.

1 Like

Maybe a compare and contrast of what a good shape vs a bad shape looks like could be helpful. A detailed view into why something is defined well and why certain errors often come up and what makes them unhelpful. Seems like so much confusion comes from not understanding more about how to write a good pitch.