Looking for ideas in how to go about providing an estimate for project completion, when a fairly large percentage of backlog is not defined enough to confidently assign story points. This is a management request and we have to provide something. For the portion of the backlog that is defined enough to assign story points on, we can use our current velocity to forecast that portion out. However, for the remainder of the backlog I am not sure what to do. Was thinking about rough T-Shirt sizing (S/M/L) and equating each size to a unit of time. S = days, M = week, L = weeks. Then multiply the grand total by some percentage to add padding for all the unknowns. Any ideas or advice would be appreciated!
Asked
Active
Viewed 1,456 times
5
-
3This question has two good answers, but there is still one nagging thing: why are they asking? You need to know this first. Is it a regulatory requirement or deadline you are using to meet? Does the business have a long term vision where incorporating user feedback isn't that valuable (and therefore Scrum might not be that valuable)? If you do edit your question, make sure the changes do not invalidate existing answers, otherwise consider writing a new question. – Greg Burghardt Mar 18 '23 at 12:59
3 Answers
15
Estimating the completion date and agile methods are at odds, perhaps even incompatible with each other.
If you're using agile methods, like Scrum, and are getting value from them, then you have accepted, among other things, that requirements change and work is emergent. Instead of having processes and bureaucracy around change control, you deliver working software frequently, get feedback, and incorporate that feedback into your backlog.
Because requirements, and therefore your backlog, change, getting too many of the requirements sufficiently detailed to design, develop, and deliver is wasteful. Consider maximizing the amount of work not done (one of the 12 principles of Agile Software Development) or deciding as late as possible (one of the principles of Lean Software Development). It is not an effective use of time (and therefore money) to refine too much of the backlog too far into the future, especially since you're acknowledging that the backlog will change, which includes removing work that is found to be unnecessary.
Forecasting completion of a poorly defined and changing body of work is not something that you can do with any amount of accuracy. When you combine the other uncertainties that exist in human endeavors, the ability to estimate gets even worse.
The first step should be to understand why stakeholders want an estimate of a completion date and what they would do with that information. There are likely alternative ways to give them better information that will allow them to achieve similar results.
Thomas Owens
- 79,623
- 18
- 192
- 283
11
The method you choose for estimating does not really matter.
What matters is that in your answer you include enough uncertainty, and make that uncertainty visible to the management by giving them a "from - to" answer, not just a "one-point". A "from-to" answer can often just found by some educated guess - "story points" and "velocity" maybe more accurate, but rarely to the point which management is interested in.
Be aware that for certain points of your backlog, the answer might be
"This item might require anything between 3 weeks and 3 months, depending on what the stakeholders want to be included in detail, which we will start to work out with them two months from now."
You can do this for all of your items and sum just the lower and upper bounds up to come up with a total lower and upper bound. But be prepared management wants also know which item cause the highest uncertainty, and why - so you should not just tell them those final sums, but also give some answers where the uncertainty does come from.
Note also:
This is rarely a "one-way" process: often, the question is not just "will this take 3 weeks or 3 months", but "what can we get in return for 3 weeks work, and what for 3 months". So the required time is not just a "mathematical function of the requirements", but the requirements can be also "a function of the available time", to some degree.
You need to include some extra buffer for items which are not even yet in the backlog, because they are not known yet. Depending on the specifics of the projects, this buffer might be anything from 20% to 200% of the items you already know and estimated.
See also:
Doc Brown
- 199,015
- 33
- 367
- 565
-2
"Is ready when is ready". With a complete backlog to estimate is to guess. When the backlog is incomplete is high odds guessing. Rather than guessing a minimum viable product should be defined instead and the stakeholders should be informed about the development progress. The downside is it cannot be taken into consideration to synchronise the product launch with other fix date events from inside or outside the business, although trying to do this is fantasising about providing something that doesn't exist sometimes is brought into discussion. The upside is the resources invested in continually estimating the remaining development could be invested in development.
