In my last post I talked about Estimating, and how I don't believe in the #noestimates movement for most situations. As previously stated, for my team, not estimating is not an option.
Below you'll find some "What If" scenarios - demonstrating the clear advantages for estimating.
We usually take the client through a Story Mapping session where we "seed" the Product Backlog. Then, based on our team's historic Velocity, we plan out Sprint 1 and check against our capacity. We use that information to determine the Velocity and to plan out the rest of Release 1.
See the previous post if you want to catch up.
Using the method above, let us say our team calculates that it needs 14 sprints, plus or minus 2 sprints. We propose to the client that it will range from 12 to 16 sprints. Now that we know the sprint count we can also give them an estimated cost.
Let's say 2 team members and a Scrum Master cost $25,000 for a two-week sprint. This project will cost from $300k to $400k. It will be delivered in 24 to 32 weeks from the start date.
Here's where we get into the back-and-forth with the client.
What if the client says they only have $200k to spend? Well, that's 9 Sprints of work. We will either work with them to A) cut out some of the functionality or B) cut back on the bells and whistles of different aspects of the functionality. Until we get down to 7 sprints so that we can still have our +/- 2 sprint factor. The reality is usually a combination of both.
What if the client says they only have $200k to spend but it has to have everything, and they can't cut anything out? Again, we'd emphasize on cutting back the bells and whistles to give a true MVP and cut it back to 7 sprints. If they don't want to budge on that. We'll show them what features will probably make it in. Then we'll ask questions, do they want to give up quality? Do they want to give up better designs? If they can't come to terms with that, then it's not going to be a good fit. We'll suggest trying another vendor that will lie to them.
We might suggest doing 1 or 2 sprints for $25k - $50k and go from there. You can cancel at anytime. Because we know once they see our process with 2-week reviews they are blown away and impressed and they finally "get it."
What if the client says they need it sooner? Sure, we can deliver sooner. I'll add another member to the project. The cost per sprint goes up, to $35k based on our example above, but the timeline shrinks. We'll mock Sprint Planning again on Sprint 1 and fill the team's new capacity. Based on that, we'll give the new timeline and estimate. Maybe it goes to 10 sprints plus or minus 2. So 8 to 12 sprints (16 to 24 weeks), $280k to $420k.
What if the client doesn't like the project overhead? Typically this is in the form of the Scrum process, and the events and activities. Our team will be in a Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retro. With a Backlog Refinement activity once a sprint. Customers usually see the value in Sprint Planning and Sprint Review immediately. The Sprint Retro is where they usually pump the brakes. Yes, the client pays for these hours that the team reflects to adapt the process and increase Velocity. If they're not comfortable with this, then it's not a good fit, and we part ways.
What if the client changes their mind later after we have started? Great, we embrace change. We gave them a box to work with-in. The timeline and the budget. They can change or add new features if they take something of equal value or more out. We try our best to visualize this to them.
Can you think of other "What Ifs" that I could add?