The post discusses, how estimates can be given at an extremely early stage of a project. A specific form of planning poker is proposed including some kind of risk estimation.
I think, everyone who works in some role in software industry has done some estimations. If you were on the lucky side, you could do the estimations via planning poker in a team. Those estimations usually are more or less reliable. But you can do so only when you have a team.
At a starting of a project – especially larger, strategic projects – you don’t have a team. You are full in the planning, starting phase. Probably first members of some teams are already on board, but usually the teams are not tailored yet.
But everyone starting from the board members to the future program and project leads are asking about costs. So, you are forced to give some estimates – even more based on that managers are forced to create certain staff plans. As an architect, you are asked to give cost plans for soft- and hardware inclusive cloud costs. At that moment in time, no one knows anything. But the planning needs to be done, otherwise the project can’t go on.
To find out which technology can be used, and which systems are needed, you can rely on you experience more or less. To give estimations is a complete different story.
There are quite good different estimation techniques known (see some selected literature listed at the end), but I feel none of them can be applied to this particular situation. Mostly those techniques try to include more and more data, but as early in the project as in such a strategic planning all of those data are not known. Remaining is only to compare the project to be planned with projects already done (with all the risk such comparison might include).
But, but, but, ….
Again, imagine the situation, I described here. It is only at the very beginning of a long journey. We don’t need estimations based on hours or even days. We need estimations on a much larger scale. Even more at such an early stage of a project no or only few requirements are known, the whole project is more or less only a collection of ideas. Anything like work break down or even risk mitigations are not known. Therefore, use a functional decomposition on a large scale.
- Assign to each business function a service.
- Try to determine which supportive functions are needed e.g. authentication service or geo-localization service.
- Play a planning poker for each determined service.
What – Planning Poker? First, I said, I don’t have requirements, I even don’t have a team to play planning poker. And now I said: “Play planning poker?” How should it go?
We need to look for the stakeholders, first member of some teams, program managers, a.s.o. With those we can play planning poker, relying on the experience of those. Even though they might not have any experience with implementation by themselves. They definitely have experience with software development – even from the outside. But if we estimate larger parts of an application, we don’t have some kind of manageable pieces as in a classical work breakdown. Therefore, we can’t estimate in days or even hours. User story points make no sense as well – we don’t have a team and comparable pieces of work.
I propose to estimate in sprints. Usually, you would have a gut feeling, what can be done in a sprint. Use the known Fibonacci series for estimates with 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Such planning pokers follow the same planning poker rules as planning pokers in a sprint planning. First round – discussion – second round – result.
OK, now managers don’t ask for sprints, they ask for costs. You might know the day rate of your developers and testers. The costs for one sprint can be estimated as follows: a team is built by 7: 1 product owner, 4 developers, 2 testers. The product owner is not counted for implementation costs (at least in my sample J). A sprint are two weeks (in my experience a good length, but you might think differently). In that way, we have 6 by 10 days – means 60 days gross. When we count 0.5 days per team member for sprint planning, 0.5 person days for sprint closing, 20’ per day for stand up, and 2% of all time for everything else, we have 50 days net roundabout per sprint.
But that is not the truth alone. Of course, we need to determine the risk as well. Again, we don’t have any information about it. Again, trust your gut feeling. Let the member of the planning estimate the risk as well – I propose to do it only in three steps – high, medium, and low. You can define, what it means: high means add 80%, medium 50%, and low 20%. That risk allows you to add something, you don’t know exists.
With such a rough estimation, you get some more or less reliable estimates even at a quite early stage of a project. Of course, those estimates need to be refined over the project. But I think, such an estimate is better as no estimate.
Laqrichi, S., Gourc, D., Marmier, F.: Toward an effort estimation model for software projects integration risk, Université de Toulouse, Mines Albi, Centre Génie Industriel, Toulouse 2015, https://arxiv.org/pdf/1509.00602.pdf
NN: Effort Estimation for Software Development, http://open-works.org/?e=effort-estimation-for-software-development
Madsen, S.: 10 guidelines for estimating project effort, Bergen, Netherlands 2011, https://www.susannemadsen.co.uk/blog/10-guidelines-for-estimating-project-effort
ANNEGRET'S ARCHITECTURE 