Every boss needs two kinds of information, exceptions to plan that require action and a status picture for education. — Frederick P. Brooks, Mythical Man Month
Our managers and stakeholders will often ask the question, “when can I have this completed?”
Keep track of these metrics that matter, the KPI’s that can influence the outcome. Here is a significant sample project with 500 users’ story points. All stories, in this example, are of the same size and complexity, story points.
Using the Velocity of a team, I can project how many sprints are needed to complete the backlog. Therefore I can estimate the sprint release and the time of completion.
If I have 500 points estimated and the velocity is 7 points per sprint, I need 72 sprints to finish the backlog. If each sprint is 10 days, then I can project the date on the calendar.
See the table below. It shows how to move across sprints carrying forward any residuals.
| Sprint 1 | Sprint 2 | Sprint 3 | Sprint 4 | Sprint 5 | |
| Backlog size at start of sprint | 500 | 499 | 497 | 492 | 485 |
| Sprint Backlog Committed | 10 | 8 | 8 | 9 | 9 |
| Sprint Backlog Completed | 7 | 8 | 8 | 9 | 9 |
| Team Velocity | 7.0 | 7.5 | 7.7 | 8.0 | 8.2 |
| Items added to Backlog | 5 | 4 | 2 | 1 | 1 |
| Bugs added to Backlog | 1 | 2 | 3 | 2 | 1 |
| Items removed from Backlog | 0 | 0 | 2 | 1 | 2 |
| Sprints Estimate to Completion | 71.29 | 66.27 | 64.17 | 60.63 | 58.05 |
| Allocation % for new Bugs/Rework | 1.00 | 0.95 | 0.95 | 0.90 | 0.85 |
| Weighted Sprints to Completion | 71.29 | 69.75 | 67.55 | 67.36 | 68.29 |
| days Exploded for 10 day sprints | 713 | 698 | 676 | 674 | 683 |
| Projected Completion Date | 3/28/2021 | 3/13/2021 | 2/19/2021 | 2/17/2021 | 2/26/2021 |
There are three types of software projects, and we must estimate for each of these cases.
- Fixed Date; the launch date has been set in stone
- Fixed Scope; the Scope has been defined where the product is not market-ready until these features are ready.
- Fixed Date and Scope; A high stake contract and widespread promises make this is the granddaddy of issues because of its difficulty and pressure. The urgency of the boss forces developers to agree to unrealistic schedules.
Estimating is the mark of a significant project manager/lead because estimates are not treated as estimates. Still, instead, it spreads as gospel that the savior is coming on the said Date. Estimators have to be very precise, but you rarely control what you are to build (specs).
The accuracy of an estimate depends on two things. First, if the current project has been successfully done before, or two is close enough to something that has been successfully done.
There are dependencies on other programs and programmers. It takes forever to build anything significant, and the product can be obsolete when it is finished.
The cone of uncertainty can lead to as much as four times as much time needed, aka underestimating or a quarter-time overestimating, so there is time remaining. Neither is ideal, but the latter is far better than the former. The main contributors to the variances are:
- Scope Changes; Incompleteness and inconsistencies become apparent only during implementation. When the software materializes into the business hands, there are many, “oh, I forgot to tell you that… and we cannot go live without it.” comments
- Unforeseen Issues: Establishing a detailed technical requirement is the most challenging part of the conceptual work. If not perfect, then development might hit a dead end after days or weeks of progress. Each task has a nonzero probability of failure or slippage. The likelihood that all will go well is near zero. It is usually an impasse that must force a change in direction from the original plan that uses lots of time and energy from developers. No other part of work so cripples the product if done wrong, and no other part is more difficult to rectify later. Project time split should be 1/3 planning (yes, this costs a lot), 1/6 coding, 1/4 component test, early system test, 1/4 system test with all components.
- Resource issues; people get life issues, emergencies, or even vacations that can change the team’s velocity. Each time you add a team member, the team’s dynamics change, and its velocity changes. Each re-formation must undergo Storming, Norm-ing before it can go back to performing. This cycle is just human dynamics at work.
If you happen to get the Fixed Scope/ Fixed Date type of project, then the first course of action is to define the effort needed to do the work. If it surpasses the Fixed Date, then immediately go read the book. “the mythical man-month” by Frederick P Brooks, Jr. before you start the manic hiring process.
Frederick P. Brooks warns us that in software, man-hours and months are not interchangeable. You can’t add more men (beyond the midpoint) to make a project go faster. Projects in the later stages need hands but not new people who want to improve and change their current course. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. Cost varies with the workforce, but progress may not depending on the stage of the project!
The most important thing you can do is manage the Scope and the stories’ dependencies in the product’s Scope. It is crucial to have iterative extraction and refinement of the product requirements, which sprints will manage. Try to reduce story dependencies and overall Scope as much as possible. Effectively this means you must be a master of the project backlog and its task relatedness.
There are two types of communication: training-related and task-related. The real drain is task-related intercommunication, which increases level of effort by n(n-1)/2 with each new team member.
So team-of-3 requires three times the intercommunication of team-of-2. And team-of-4 requires six times the intercommunication of team-of-2.
–Frederick P. Brooks
Stephen Choo Quan
Thanks for reading and Sharing ❤
