In Scrum, Everything is 100% Complete. Really? Not So Fast!
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.
Years ago I worked with a guy whose last name was Dunn. My boss used to call him “not Dunn” because he never seemed to be able to complete anything. That always made me laugh, but in the end, it’s not really that funny because if people can’t finish anything then chances are they get a pretty bad reputation in a company.
I thought of him while reading The Scrum Guide™, authored by Jeff Sutherland and Ken Schwaber. One of the three tenets of Scrum Theory is Transparency which the authors describe using two examples. One of them is as follows:
Those performing the work and those accepting the work product must share a common definition of ‘Done.’
The concept of percent complete has always been subject to a wide range of varying definitions and interpretations. What is 50% complete to one person, or group, may not be to another.
For example, the project manager may report that the project is 50% complete because half the resources and costs have been incurred and the deliverables are well on their way to being completed (even though nothing has been delivered yet).
The client, on the other hand, who may also be obligated to making progress payments based on percent complete, may think it’s a lesser percent because they haven’t received half the benefits or inspected or reviewed “half” of the deliverables. Without an adequate inspection system, or prior agreement as to what 50% complete means, it’s one person’s word against the other’s.
Let me present an interesting example.
I took this picture of the front window of the Metropolitan Transit Authority’s (MTA) Project Office on 2nd Avenue in Manhattan. The sign informs the neighborhood the progress made on this megaproject. As you can see, MTA reports the project is 82.3% complete.
What does that really mean? Does the .3% make you feel that they really know what they’re talking about because it conveys a sense of accuracy? Your guess is as good as mine.
As a consequence, it’s always been sort of a game, and a guessing game at that, to determine percent complete. It’s a lot more art than science. And, when you add the obligation of progress payments based on percent complete, disagreements are more the norm than the exception.
I don’t see this issue magically disappearing because of the concept of Done in Scrum. As far as I can tell, what is Done is the deliverable to be produced at the end of the Sprint. But what percent complete is the entire project based on one deliverable generated by one Sprint? It’s a rhetorical question, so if you have a rhetorical answer please speak up!
I have no issue with Done; in fact, I think it’s a great idea to have all parties agree as to what that means. But to avoid potential disagreements I think the lessons of the past can apply to Scrum projects as well.
For example, in the earned value method (EVM) a task was recorded 50% complete the day it started, and 100% complete the day the requirements were met. This took all the guesswork and differing interpretations out of the equation so that the project manager and client could at least agree, at a high level, just how far along the project was and how much the buyer had to pay the seller. Might this work for Scrum? Maybe, maybe not.
As for this post, I think I’m Done!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.