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?
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
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.
I feel the wording in the book could be improved to make this a bit clearer. However I’m almost sure that slices and scopes are being used interchangeably as they are representing the same logical concept. For instance, in this chapter the book says:
As we saw in the previous chapter, the slices of work integrate front-end and back-end tasks. This allows us to finish one slice of the actual project and definitively move on […] We call these integrated slices of the project scopes.
So in essence, a scope is a slice (of integrated work) that can be validated end to end (mostly). So when the book says that “scopes are more than slices” I think it only wants to draw our attentions to the fact that it also acts as the language of the project and not necessarily that they are different concepts.
Even in potato-shaped diagrams, you can see the analogy between DDD[1] bounded contexts[2] and Shape Up scopes.
“Scopes are more than just slices. They become the language of the project at the macro level.”
In this way, each scope is like an entry in the ubiquitos language[3] glossary of to the specific bounded context which your team implements in the larger organization.
Similarly as we divide a business into core domains and supporting/generic subdomains and map them to bounded contexts, we repeat the same process recursively within bounded contexts, dividing them into independently delivered vertical/integrated slices.
Just as there are usually no 1:1 mapping between subdomains and bounded contexts, the same is true with slices and scopes. But in the simplest cases they can be 1:1 mapped.
So I would say that a better name for the “Scope” would be “mini-” or “micro- bounded context” - microBC/μBC
Problem Space
Solution Space
Methodology
Subdomains
Bounded Contexts
DDD
Vertical Slices
Scopes
Shape Up
This approach may be overkill (especially for short cycles), so it may be much better to treat the entire pitch as a single deliverable with a known product impact / business value. I doubt that every single scope/slice will have a significant impact on business metrics.
With that said, something like Enanced Scope Maps[4] can be useful for determining which scopes are nice to have, which are must-haves, and in what order to implement them.
