Product Owner is requesting a “confidence check” for reaching the MVP - How to in a Scrum project?

We're in a quite complex software engineering project with lots of unknowns due to new technologies involved that the Team has never applied nor have comparable experience.

Due to these risks the Product Owner (PO) requested a "confidence check" of if the Team will reach the minimum viable product (MVP) by a certain deadline this year. Since "deadline" and doing Scrum clash quite a bit, the Team was really hesitating to give the PO an answer.

The PO required to have this indication for a CEO's report; thus, all had to rate it; there was no way around. So I took the rating as part of a Retrospective. We're in Sprint 2 of 8; the real velocity is not clear to the Team yet.

He asked the Team to vote 1 - 5 regarding these phrases:

Here's the result I'd like to share. The Dev Team is quite large, since we have multiple streams - some votes are also from people of an extended Team.

I'd like to get your opinions on this.

5 Answers
5

While such a confidence check is nothing that you'd read about in Scrum Guide I don't see it as something that violates Scrum in any way. It is, in fact, answering a different question: the one about confidence of people, not the one about forecast end date.

The native method to answer a question about expected end date in Scrum would be based on Velocity and backlog size. I would argue that simply counting throughput (a number of features completed) is simpler and yields similar outcomes. No matter which method you use it can inform people about their confidence. For example: throughput / velocity measured so far suggests that we need 9 more iterations to finish the backlog, but we are in sprint 2 of 8 thus we only have 6 iterations left; thus my confidence for making it on time is low.

Another bit that can inform confidence would be scope creep: how many features are being added to MVP backlog over time. The fact, that you have e.g. 25 features in the backlog for the remaining time means little if you can expect that each iteration adds 3-4 new features to the backlog. In such was the case you would need to take into account that the real backlog size may be more like 43-49 features than current 25. This, as well, would inform confidence of people.

On the validity of the method, I don't see it much of a problem as long as there is a common understanding between the PO and CEO what the measurement actually means, and possibly all the caveats to the quality of the measurement.

A few observation that one could draw looking at the picture:

The above remarks also suggest how the activity could have been improved: make 100% sure that the team feels safe about the gathered measurement, make sure the CEO understand the caveats and the team knows that too, give space to "have no idea" about own confidence, make sure it's anonymous, etc.

Andre welcome to the forum!

I suggest you to:

I don't think that it's a massive problem to ask for a confidence vote. I often do this with raising hands as a yes and no or we use fingers instead of a scale like you have.

As long as the team doesn't think that a confidence vote is taken as a commitment or like a signed agreement that they will deliver on a fixed date.

Most organisations put in fixed dates and this is often a sign that the people that define these fixed dates need coaching to understand that on Agile projects we use landing zones, velocity and scope as our levers.

A better way of doing this is to get the team to estimate 2 sprints worth of ready for dev work and then estimate the rest of the backlog at epic level. Plug all this data into a burn-up chart using their average velocity of the last 2 sprints and then constantly update it as their velocity figures come in every sprint (Jira does this automatically). This burn-up chart will give you a landing zone i.e. a date range. If its completely off, then you need to have a hard look at your MVP, remove distractions and other work the team might still be responsible for, if its still completely off, you would need to discuss any architectural bells and whistles which may need to be removed. The worse case scenario is you would need to have a difficult discussion with the CEO and PO coaching them on and showing them these charts.

coming in a bit late, but I've done this a few times, though not specific to Scrum:

Getting an honest evaluation of your team's confidence in stuff like this (launch dates, complete requirements) is really valuable, but challenging:

Honesty: Self-reporting on the spot is tough -- you want people to answer somewhat thoughtfully, but also without influence from other team members. AND without feeling like they're committing to something.

Ideally, figure out a stress-free way to do this anonymously. Takes away the pressure of being "right", but also gives people time to be thoughtful in their choice.

Trajectory: If you're only asked once, it can feel like your answer will be taken as a commitment ("We're way behind, but Jane said three months ago she was really confident in the date -- what gives???").

Ideally, poll regularly, and track the trend over time. Seeing the line trend down or up is more valuable than any individual number.

I've done this manually on a few projects, and it's been super useful to see things like: Launch date confidence was low, so we probed a bit more, found out team wasn't confident we'd got all the reqs captured, so even though all the boxes were being checked, no one was sure how anything would come together in the end.

So useful, but a bit of a pain logistically (extra busywork to send it out, collect results, calculate stuff, etc.).

(Pain enough that I actually just wrote an app (ProjectPoll.co) that does this for you; if you're interested, feel free to make an account and ping me, I'd be happy to set you up with a project to try it on.)

This is a great topic!

Estimating confidence on a regular basis (at Retrospectives) will be useful in gauging team health and professional growth as everyone works in this new territory. The Scrum Master should direct the process:

The Scrum Master surveys the team with an anonymous vote (1-5), insert the data into a histogram & discuss the results as a team immediately.

Discuss the individual week's "score" and then trend.

Ideally the confidence #'s move left (4's & 5's get bigger) as User Stories are worked through/revised and knowledge is gained.

Keep in mind:

Good results start with well defined User Stories (not hopes).

Agile development yields product and knowledge (both are valuable).

The Dev Team & Stakeholders should talk directly regularly at Sprint Reviews.

Stakeholders' needs can change as information/situations evolve. Be transparent and communicate fearlessly. Good luck & go get 'em!!

Thanks for contributing an answer to Project Management Stack Exchange!

But avoid …

To learn more, see our tips on writing great answers.

Required, but never shown

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.