When all "Must Have" (re: MoSCoW) stories have been completed, should the Scrum Master ask the Product Owner if the project is over after each sprint?

Question

I see the value in being proactive, rather than waiting for budget or time constraints to catch up on the project. On the other hand, I don't think every project should be a race to arrive under-budget and under-time, at the expense of a proportion of "Should Haves" and "Could Haves".

One of Scrum's primary objectives is to produce high quality increments of deliverable product. It is not, primarily, focussed on delivering products under-time and under-budget. (although it can do so) I think that asking the Product Owner if the project is finished, at each sprint after the "Must Haves" are completed, potentially shifts the focus to delivering a minimum acceptable set of features, rather than using the time and resources available to deliver the maximum quality of product possible.

I believe the Scrum Master should keep a watchful eye on the constraints, while not necessarily striving to end the project as early as possible.

Answer 1

This is a really cool question! First, to answer it directly, there's always the implicit question at the end of the sprint "Is this project finished?" Or, to flip the question on its head a bit "Will spending the money to develop the next set of features create a reasonable return on investment?"

When you reach that point is really the product owner's decision. It might be right after the must-haves are complete or somewhere through should-haves, or even later. There are lots of ways to evaluate if features are worth developing. I'm personally a big fan of Lean Canvas. This blog covers a great approach that adapts Lean Canvas for exactly this purpose. As for if the scrum master should be the one asking, he certainly can, but he's basically asking the PO "Are you doing your job?" so the question should only come when it's really appropriate or needed.

Finally, if you haven't already, definitely take a look at Lean Startup. Getting your product out in front of customers early and often will help create visibility on when it's right to keep developing and when it's write to either wrap it up or pivot on your product's directly.

Answer 2

This is a very interesting question. For me, I think it depends on the business, and the PO.

If the business is not doing well and time to market is paramount over budget, get to production! Deploy it and keep iterating as value is still being achieved.

If the business is doing ok, I think gauging the PO is important. Do they have a good understand of their user base? Were the must haves extremely bare bones? Or are the must haves actually good enough? I get the sentiment of not wanting to end the project too early, and I think there are a number of nuances to consider when making the decision.

Answer 3

Typically Scrum is used for product development and not for project work. With product development you have a prioritised product backlog that is continually being added to and refined. There is no 'end of project' as such. It is an ongoing piece of work.

I have worked with some Scrum teams that are involved with several different products. In these situations there needs to be a prioritisation of the work for the various products. The team might spend 3 sprints working on the priority features of Product A, then switch to 2 sprints working on the priority features of Product B. Prioritisation at this level is strategic rather than the more usual tactical level prioritisation that takes place with a single product owner and single product.

Answer 4

A goal of scrum is having something ready after each sprint. Following this, releases or deployments a possible in short cycles.

In your case, the company might release the product to satisfy market demands and start to earn money while product development or improvement still continues.

This depends on the product strategy a lot fore sure.

So, talking about software, this is an approach applied quite often.

Talking about projects including hardware, it's about the product owner to identify the budget-to-function optimum.

But scrum comes from software projects, so in my opinion applying scrum on other kind of projects might need some adaption or interpretation :)

Answer 5

No.

The product should always be deliverable at the end of a sprint. So they can ask, 'Shall we deploy this version?' But the prioritization of tasks into categories is only a concern for the Product Owner.

In 'real life' there's always going to be a deadline and a set of features without which the product wont be worth taking to market. The 'Must' tasks should help the PO see whether the team is on track to deliver that minimum spec before the deadline and prevent the injection of non-'Must' tasks jeopardizing that goal.

In my view you are right and there can be a tendency in scrum to want to 'finish' projects rather than be enthusiastic about new work. I think this can be combated by have version 1, version 2 etc of the project and by allowing technical debt/rewrite tasks at the start of new versions