Should we think about scopes during shaping?

Our team kind of struggles with scoping. I know it’s inherently difficult, but in 6 months I’ve gotten one team to scope a project as outlined in Shape Up and I’ve been wondering if it makes sense for a pitch to have some opinion about what the scopes should be.

My goal would not be to prescribe scopes – just to suggest some as a way of pointing the team in the right direction.

Has anyone here included scope suggestions in a pitch or, maybe more importantly, considered scopes during shaping? Or does this idea seem off-base?

1 Like

If the team needs help scoping, it would be better to coach them during the cycle than to try and specify the scopes up front. Why? Because you can’t actually see how to draw the lines between scopes until you get your hands dirty in the work.

In the past when I’ve had teams who needed help with scoping, I would give them a few days to get oriented and dump the tasks they discover into some kind of catch-all list. I would ask them to make an attempt to scope. Then we’d workshop what they did and come out with different scopes when necessary.

IMO it’s better to create this teachable moment than to try and do more design up front.


Ryan’s advice on coaching is solid. For what it’s worth, here’s what our team does.

Our shaping team avoids scope altogether. We use a construct called a target condition to “theme” each cycle. Here’s the target condition from our second cycle:

‘When I feel unsure about reaching out to [our company], let me find information online, so that I can trust [our company] actually does what I’ve heard of them.’

(The wording is weird because we use Shape Up for marketing, not product, so our target condition is always written in the potential customer’s voice.)

The big batches of shaped work are all aligned to this target condition, but the scoping is left purely to the delivery team. Since I’m also on the delivery team, it’s easy for me to coach … but I’m usually hands off. Because the delivery team knows the target condition, they have a good compass for managing their scope. Either their scope gets them closer to the target condition, or it doesn’t. I’m willing to let them learn that on their own.

Using target conditions has had two unexpected side effects on the delivery team. The first is an increase in unsolicited pitches. It spurs them to think of other ways to achieve that target condition that we either haven’t shaped yet or flat-out missed.

The second is questioning our shaped work and actually doing additional demand-side user research during the cycle. This happened just last week. I’m not sure how I feel about it yet, because in theory research should take place on the shaping side. Still, I was pretty excited that someone felt confident enough to push back and be skeptical of the research behind the presumptive “fully shaped” work.

Anyway, tl;dr – we solved the scope issue by ignoring it for the most part in shaping and then passing the buck in full to the delivery team—but give them a target condition “compass” that hopefully keeps them pointed in the right direction.

Awesome, Nelson. FWIW, our team also regularly questions and debates aspects of shaped work. My perspective is that it’s super healthy and should help us improve pitches over time to get them to the point where any research the team would need is available to them.

All that to say, I feel ya :slight_smile:

Could you help me better understand the through-line from themes to scopes? I get how themes affect shaping/pitching, but I don’t understand how they would affect scopes.

And just to make sure I’ve got my terms right, when I say “scope” I mean an orthogonal slice of work within a pitch that you could call “done”. Flagging @rjs to make sure that’s correct.

I’ll give you a concrete example from the theme I shared earlier, which is how we connect themes to scope. During shaping, we do write up some “scope-level” suggestions to our shaped work, e.g.

• Write a Medium article that boosts credibility
• Write a LinkedIn article that boosts credibility
• Add one or more customer testimonials to our web site
• Add one or more case studies to our web site

Any combination of those could satisfy the condition of “done” six weeks from now.

But for the most part, we don’t commit the team to anything on that list, and usually, we don’t even share that list with them.

We use the list to gauge whether their scope commitment as a delivery team lined up with what we were hoping for as a shaping team. So far, it’s worked well enough for us to avoid any intervention. =)

We’re still trying to refine this approach ourselves, so apologies if our theming approach doesn’t apply well to a product context, which may need to be more prescriptive in terms of defining scope guardrails to a feature or new capability. With marketing, we get to shape with more “squishy materials” if that makes any sense.

What I mean by “scopes”

Got it @nt-from-chicago. Thanks for the helpful details.

This may be because you are talking about content creation and not software production, but I believe I am talking about something different when I say “scopes”. Let me know if you disagree, though.

Borrowing your example, suggestions like writing a Medium article or adding testimonials to the website sound more to me like the level of prescriptiveness in the strategy (i.e., what to make).

What I was asking was more about execution (i.e., how to go about making it). Using your handy example, this would mean we’re assigning a pitch that says something like…

Boost credibility by writing an article on Medium (and anywhere else that seems reasonable), and by adding some testimonials and case studies to our website.

We would not tell the team what precisely to write, how long it should be, what the tone should be, etc. We also wouldn’t tell them where to start or how to think about their order of operations (which is the thing our teams have struggled with a little bit).

Where I’ve landed

After re-reading Chapter 11 on Mapping Scopes and thinking about how we work, I believe our team is actually more on target than I thought.

I was complicating things by taking “get one thing done” too far. I was inserting a user-facing requirement, and I don’t think Shape Up is that rigid.

If every scope turns out to be a user-facing release, awesome. But the main goal of a scope is to be able to call an independent piece “done”.


I like that hierarchy of fidelity diagram. I’m going to soak that in. I’m glad to hear that you feel your team is not so far off after reading Chapter 11. I believe that my examples don’t map well to product teams, so we’re in agreement there. Thanks for sharing your thoughts. They have been helpful to me to think about the intent of scope.

1 Like