You’re working a project (it could be “waterfall” or “agile”). The project involves drilling a series of holes through the long axis of something rectangular (maybe a piece of aluminum or glass). This piece is critical to your project, so everybody and their boss wants to know progress.
The “agile” folks could observe that this is a great opportunity for an “information radiator”: a poster everybody and their boss can see just by walking through that informs about that particular progress. It radiates and broadcasts the information; no one misses it. That’s a good suggestion for waterfall, too.
Our reporter goes to the shop and watches preparation of the raw material. Maybe it’s cut to size and smoothed. It meets exit criteria for a requirement, “Prepare rectangle.” or for a user story, “As a sailboat operator, I want a sturdy rectangular piece with twenty holes drilled in a line so that I can use a pin to effectively change the length of the rope attached to this rectangle.” (People experienced in sailboats are probably rolling their eyes and saying, “This guy doesn’t know anything about boating!” True, true. No denying it. Hang in, please, for the real point. It’s coming! And it’s not about boating.)
The rectangle met exit criteria (which we ought to have in both waterfall and agile; often we have them, but they’re not formally written). We can continue the project knowing that task or user story is complete. Next … the drilling.
The project has decided that the drilling will occur under a task, “Drill holes in the rectangle.” or under a user story, “As a sailboat operator, I want a series of holes in the previously prepared rectangle so that I can use a pin to effectively change the length of the rope attached to this rectangle.” (Both examples could be improved with more specifics, perhaps with the number of holes. True, but please accept this for the point I’m making!)
The shop drills the first hole. All’s well. Our reporter needs to file a progress report.
Key question: If the design calls for 20 holes, does our reporter inform everyone that the task or user story is 5 percent complete?
For decades, some in projects have argued against that report. They might argue that the only criteria for reporting progress is fully meeting exit criteria: you’re either “done” or you don’t take credit for the work. They might argue that if the piece breaks along the line of the holes we’re drilling, we were never any percent complete; we just didn’t know that, yet. They might argue that our teams function better if they know they have to complete all the defined work to get credit; we don’t want to operate with the ambiguity of taking credit when not really done.
One very funny cynic (I wish I could give proper credit) observed that, “The second 90% of the project is the tougher part!”
Of course, in all the decades people argued for reporting only completions, they received feedback that they weren’t much in tune with management realities. There has to be feedback on progress to management, investors, and others. There is often lots of pressure to bend on this perceived minor point.
Many agilists have weighed in on the side of reporting only completed exit criteria. They suggest that the Product Owner has sole responsibility for determining “done” and suggests the Product Owners use only exit criteria for their determinations. Often they suggest that user stories get their marks for “done” primarily (or only) during the “Product Review” ritual (there are lots of equivalent names in use) just before the end of the iteration. They suggest that if a team demonstrates that work is “done all except for …”, a Product Owner serves the team best by not allowing them credit for that work during the current iteration.
Some would argue that the best response in the waterfall world is to break the drilling task into a series of smaller tasks, each of which have appropriate exit criteria on which we can report. And … the size of the work then described? It’s very similar to the size of work that works best for user stories in the agile world! (Not a surprise if we think about it!)
And what’s my position? (Not that it really matters …) Given the opportunity, I advise executives and investors to ask for complete or not; nothing between. With any luck, they’ll also ask the project teams to drive analysis down to small units of work (like agile does with user stories). I seldom get that opportunity; there is usually more important change to advocate in my clients’ processes and I choose those suggestions carefully. Having made that decision, the project can report steadily increasing progress each period; I know there’s measurement error in the report, but no one has ever asked to know that. Teams file the reports and do what it takes to make real progress. It’s practical. And when the project completes with functions around which we created expectation at the cost and time for which we created expectations, no one cares that progress reports had measurement error along the way.
And … this question matters: What do you think?
(An entirely different subject: I don’t have a visit counter on this blog; there’s probably a way, but I haven’t looked for it. As a result, I have no indication anyone is reading. Ever. So … following the technique of another blogger I saw … if you’re alive and reading this, please be so kind as to comment here or send me an email at firstname.lastname@example.org! I mean … if no one’s reading, at some point, I’ll quit investing the time!)