Estimate Scrum projects

Scrum relies on empiricism, so without any data to back up how quickly the team can work, completion forecasts are likely to be wrong.

How do the team feel about estimating the whole project at this stage? Do they think they can do it reliably?

This is probably the best estimate you are able to achieve right now, but it's likely to be as inaccurate as anything you would get without Scrum.

How open are you and the client to inspecting progress after every sprint, and deciding whether it makes sense to continue with the project? 

This way, the risk for the client would be limited to just one sprint, and if the team are delivering a Done increment every sprint, the client can regularly assess whether progress is sufficient.

After every sprint, the Product Owner should be able to look at past performance, to estimate what can be done over the coming sprint(s). Although I suggest the Product Owner provides something like "worst case" and "best case" forecasts.

the client asked me for a estimated time for completion for the whole project. 

How this be given using Scrum?

One Sprint is a reasonable answer. They ought to work with the Product Owner and decide if sufficient value has been delivered by that point, or if it is worth continuing with further development.

If such an assessment can’t be made each and every Sprint, find out why, and what purpose Scrum is expected to serve.

And with this in mind, the project budget can be calculated Sprint by Sprint? 

Diego,

In Scrum, 3 of the 4 project pillars are fixed (time, cost, quality).   The only variable is scope.

Perhaps you can have your client select a date when they would like delivery of the project (time).   Determine how many sprints will be completed within that time frame (time).   Your cost can be calculated per sprint (team is fixed, resources, etc.).   Quality is also fixed, determined by the criteria needed to declare an item complete (Definition of Done).

If your client ensures that your team is always working on the most important items each sprint, they still may be able to complete 100% of the project by the target date.   If not, they will still have delivered the most critical items.

Another benefit to Scrum is the ability to inspect and adapt each sprint.   Perhaps the initial project scope is found to be more or less than what is delivered by the end date, due to either changing priorities, or items deemed unnecessary, or items added once the client inspected the delivered items.

Once the team completes a few sprints (at least 3), you may be in a position to project how much of the project the team may be able to complete by the target date, provided the team has given rough estimates on the remaining work.   This way, you should know early in the process whether you are ahead or behind the targeted scope, and you can adapt accordingly.

Good luck!

Timothy,

As my first comment on this forum, I would like to follow up on your previous comment.

What make you believe that for a Scrum project, the quality attribute is fixed ?

For instance, as the team will mature (on technology, business aspects), don't you think the requirements/expectations in terms of quality might change?

Thanks 

Jean-Michel

Jean-Michel,

Yes, quality requirements can definitely change/improve, but those requirements should be captured in your Definition of Done.   All sprint stories must adhere to that Definition of Done (DoD) when completed, or they are simply not considered complete.   Quality is therefore fixed in Scrum.

Such a DoD should be well-understood by everyone on the Scrum team prior to the start of a sprint.   On occasions where the DoD is changed mid-sprint, the Scrum Team should re-evaluate their sprint forecast to ensure that it can still be met despite the new/changed DoD criteria, and adjust if needed.

My understanding (and I may be wrong)

For a project using Scrum

- The quality is captured in the list of DoD criteria (eg reach 25% test coverage) 

- The criteria can be inspected and adapted during events such as retrospectives (the Dev Team decides to increase the test coverage from 25% to 35% ).

Quality is therefore not fixed over the course of a project.

Any objection?

Jean-Michel,

It should be a rare occurrence when the DoD is updated mid-sprint, and should only be improved upon when it happens.   In almost every instance, DoD modification occurs in between sprints, so that there is a clear understanding around quality for the upcoming sprint.

Per the Scrum Guide, each "sprint" is considered a project.   Therefore, it is my opinion that quality is fixed in each sprint/project in Scrum. 

The point is that the DOD would very probably change, but quality is not a variable for the managers, i.e. quality must be high as possible (and the DOD will be more and more stringent).

Therefore, the best variable is the scope of the project, in order to have the best possible product within the allocated budget.