Avoid appetite deviations

1

When shaping a 2, 4, or 6-week cycle batch, what are the best ways to determine what looks like 2, 4, or 6 weeks so we do not write a pitch that is destined to result in deviations from the stated appetite?

Would, for example, considering Brooks’ rule of thumb for estimating help: 1/3 for planning (e.g., the product pitch and sometimes the left side activities of the Hill Chart.), 1/6 for coding (assumed to be easier to estimate), 1/4 for component test and early system test, and 1/4 for system test, all components in hand.)?

What are ways to test if problem definition is narrow enough to fit into said cycle length before people comment on pitch?

2

If there’s a deviation from the stated appetite then either the pitch was not shaped properly or the team does not understand that they’re accountable to deliver within the given appetite. Appetite is how much you’re willing to spend to solve a problem, not how much you think it’s going to take the team to deliver a result.

1 Like
3

Right, but if I say I am willing to spend 6 weeks on x, then I need to understand, when creating a pitch, what feels like 6 weeks. We might need guidelines to support people in evaluating if a problem definition is not perhaps 6 weeks, but is say 4 week, especially those who are new to Shape Up.

1 Like
4

The one thing to remember is that there is both a four week and six week version of everything. The challenge is the trade-offs you may make in trying to fit too much in too little time, and whether you’re comfortable with those tradeoffs. This is where de-risking comes in, make your best guess, then share with your engineers and designers or whoever might be building it.

Optional scope is your friend here too, make it clear as to what parts of the pitch are essential and what parts are nice-to-haves. The team can then adjust on site based on what happens during the project.

Another thing is that scope always grows.

I don’t think I’ve ever been in a place where I’ve pitched work with a six week appetite and it turned out that the team were finished and had nothing else they wanted to do after four weeks. There are occasions when they probably could have wrapped up at four weeks sure, but there’s always something else to improve. In-fact the work where that happens usually ends up being the highest quality stuff we make. Some might see that as inefficient, but in the big picture we’re able to build a higher quality product in less time than we were before so the inefficiencies balance out.

3 Likes
5

:clap: I’m finding that if the team is diligent about tracking discovered work, doing the hard stuff first, and being really aware of what’s a must-have and nice-to-have in the discovered work, then we are almost always choosing between nice-to-haves across scopes in the last quarter of the cycle.

During shaping there’s also de-scoping. It’s common for one person to look at a problem from one perspective and say, “I have a 4 week appetite to solve this,” and then for someone else to say, “I don’t have a 4 week appetite for that but I wonder if we can reframe it someway because I do have a 2 week appetite for it”. You can then go back and look at whether the bounds can be changed to fit the new appetite.

Third thing, which I think is actually alluded to in Shape Up but isn’t covered in depth - it’s really helpful for shapers to have some level of technical knowledge and understand the “internal” language of the product being built. For example, and I’m just guessing here, Basecamp has Hill Charts. To the customer there are “Hill Charts”, “Hill Chart Settings” and pretty much everything else is visibly identified, brought into view, and modified. But that language isn’t enough for Basecamp to thoughtfully discuss Hill Charts so they might have other layers that map to the model underlying Hill Charts. Hill Chart Dots, Hill Chart Dot Position, Hill Chart Dot Label, Hill Chart Versions, Hill Chart Note. When shaping, it’s helpful to understand whether you’re inventing new internal language for your product or changing existing language. For example, if in one version of Basecamp there were no Hill Chart Versions, then Hill Chart Note would mean “the text of the hill chart in the project”. If a new project introduces Hill Chart Versions, then the shaper will need to understand that the meaning of Hill Chart Note changes to mean “The text of the latest version of the project’s hill chart”. Same language, same user experience, but work nonetheless. So the heuristic for an evaluator of a pitch in terms of feasibility is “what new language does this pitch introduce, and is it well formed?”

2 Likes
6

This is true - and it makes a big difference to how much you need to rely on others to de-risk a pitch into something that feels feasible given the appetite. I think someone can still shape work without a deep level of technical knowledge but it will change how much you need to fall-back and rely on others to shape something to fit within an appetite which can have it’s own challenges.

2 Likes
7

Agree - my larger point was for the internal team to adopt or converge on the same product “language” as a means of improving communication and helping to avoid scope or other misunderstandings

1 Like
8

A distinction that I think is important to make is that, at least how I see it, problems have appetites, solutions have estimates. And not only is there a distinction, but there’s also an implicit hierarchy — an estimate is embedded within an appetite.

As a shaper with less technical knowledge, the first step for me is defining a problem, prioritizing it, and assigning it an appetite (sometimes this involves leadership depending on scope). The second step is fitting a solution into that appetite, which in my case since I lack some technical knowledge about the product, is also about gathering estimates for versions of a solution I’m working on (before it’s officially pitched).

5 Likes
9

Very helpful. I wonder if there is a heuristic/framework we can use (we know there are dozens for estimating solutions, which we are obviously trying to avoid here) when trying to test/identify how/if a problem definition fits into a 2, 4, or 6 week batch…

1 Like
10

To play a bit of a devil’s advocate to my own argument, I think the relationship between an appetite and an estimate is more dynamic than I presented. Sometimes you will have to change your appetite based on the solutions available to you. It might be that some problems are inherently more complex while others have more optionality. It also might be that I’m not a good enough shaper and there’s a 2-week solution to every problem, but I can’t say that’s my personal experience.

In terms of a framework for evaluating problems, let me know if this is useful:

I think I saw this in one of Ryan’s presentations or whatnot, but one framework I really like is the following:

No of users + Issue severity

Here’s an image of me trying to capture this (example within the image is irrelevant)

image
image1336×758 64 KB

So the 4 quadrants are like this:

  • Problems that are minor but affect a lot of users

  • Problems that are deal-breakers/blockers for the main use case and affect a lot of users

  • Problems that affect only a minor set of users (or 1) but are still a deal-breaker or blocker for the main use case

  • Problems that are minor and affect only a small set of users (or 1)

How to define a deal-breaker

Sometimes, the user helps you define this by saying it outright "this is a deal-breaker and we cannot launch/adopt/integrate your product without this.

Other times, users might not be so direct, but it would be such a big problem to them that as soon as they find an alternative, they will abandon your product. In this case, it’s useful to define what are the main actions/jobs (choose your lingo) your product is serving

For example, in my case, my product is a marketing platform so I might define it the following way

An issue is a deal-breaker if

  • It prevents my user from scheduling social media posts regularly

  • It prevents them from performing a quality review over the content

  • It prevents them from connecting a social account to my product

An issue is NOT a deal-breaker if

  • It has to do with an extension of an existing feature (for example, they want the ability to share videos and not only images in a social post)

  • It’s a request for something that is not part of the main use case. For example, they want to be able to translate a post to multiple languages within the platform

You can be really diligent and convert/dig into a request to find the problem or need underneath it, and then that would be what you can try to prioritize (so you stay relatively solution agnostic). For example, A request might be “I want to be able to translate the content of my social post to various languages or language x” — and a more demand-side statement would be “When I have clients from multiple locales, and I don’t want to spend time creating many instances for the same content”.

3 Likes
11

I don’t have a serious term for this, but I’ll show a nearly finished pitch to one of our lead devs and do an “LOL” test. We’ll ask “Is what we’ve shaped doable in X weeks?” and if they laugh, it’s scope hammer time.

We use Airbnb’s X-star experience to discuss tradeoffs between appetite and constraints/boundaries. So a six-week appetite might get us a 3-star experience, but a 2-week appetite gets us a 1-star experience. Scope hammering is what we take out of the pitch (or call them stretch goals) to get to the desired appetite.

12

Maybe the target condition should be to at least clear ~80 percent of the bet as originally scoped in the pitch through the system in a single quantum of time (e.g., 6 weeks), where ~20 percent might take multiple trips through the system or not at all.

13

Same thing I do with my team. You have to clarify the problem first, which is sometimes a challenge. Shapers come with IDEAS for implementation, but ideas are tricky.
What we do is first clarify what problem we are solving.
Then we decide how much we want to invest in that problem.
Then we come up with at least TWO IDEAS how to solve this problem.
Then we have primary validation with technical leads.
After that we start writing a pitch

1 Like
14

Would considering a modified Brooks’ rule of thumb for evaluating appetite be helpful?: About 1/3 for task discovery, 1/6 for coding (assumed to be easier to estimate), 1/4 for component test and early system test, and 1/4 for system test, all components in hand.

15

Any suggestions here, @rjs?

16

If you know how the parts connect because you have technical experience, this is not very challenging.

If you don’t know, partner up with a technical person who does.

The pitch isn’t just a fuzzy idea. It should be a technically understood, technically doable thing that is matched to the appetite.

1 Like