The Importance of Clearly Defined High Level Project Estimation
It is safe to say that software development teams work best in the confines of each iteration. All the stories are laid out, estimated, and committed to based on conversations, designs, whiteboard diagrams, and a clear understanding of what is needed to be done. The business team works best in terms of looking at technical projects as a whole as they try to prioritize and decide what work needs to be done to drive business. And this is where the dilemma lies. The business team is looking for a general idea of how long a project will take to complete, but the development team is uncomfortable in providing one until they have all of the stories in front of them. The catch-22 is that stories aren’t written until a project has been given the green light.
The development team’s reluctance in providing high level estimates typically stems from:
- A fear that the estimate they provide will be mistaken as a commitment when it comes time to actually develop the feature/product.
- Not having the chance to fully explore assumptions and risks adds a sense of uneasiness since the estimate is usually heavily based on these assumptions (mainly technical assumptions – business questions should be answered).
- High level estimation meetings can be difficult to facilitate, and can quickly become frustrating for everyone involved. It is very easy to lose track of the goal of the meeting.
At Point2 it is usually the Team Lead/ScrumMaster and a Business Analyst who facilitate these meetings. It is up to them to ensure that the pain-points are alleviated. If the team has a genuine feeling that the high level estimate they provide will be construed as an actual final commitment then there is probably reason for it. Perhaps this was what happened historically and the team is having a hard time getting past that, or maybe it is continuing to happen. If this is the case, as a Team Lead/ScrumMaster it is your responsibility to manage this disconnect. If the nature of the high level estimate is being misunderstood by your customer or business team it is your job to fix it.
If there is a lot of questions arising during estimation that cannot be answered in a reasonable amount of time, there’s no way around it – assumptions will need to be made. The key is to make note of these assumptions and document them as risks in your final estimation. This will be key in helping the business prioritize the project. If there is a lot of high risk items the decision to start straight away may be best. On the other hand maybe the risks just outweigh what we hope to gain, and the project is scrapped. The point is to provide enough information for the business to make an educated decision. It is interesting to note that a lot of these technical assumptions are due to technical debt. Minimizing technical debt makes high level estimation much simpler, but I will leave that topic for another post.
When we first started providing high level estimates I had little knowledge as to where to even start. Being a former developer I too suffered from many of the above points. The bare minimum is to get the team to break down the tech project into logical, more manageable pieces. Briefly discuss these logical components to ensure that everyone has a shared understanding. It’s at this point that assumptions are likely going to be identified.
Once you’re ready to estimate that specific items try what I’ve been calling the Goldilocks technique. Throw out a number like “2 weeks” and ask if it is too much time, not enough time, or just right. Modify your number and repeat as needed. It is a good idea to sometimes provide more than one estimate based on the presumption that certain risks may come to fruition.
If your team has the understanding that the estimate they are providing is an educated/best guess that is going to provide the business with the knowledge needed to steer the company in the correct direction, the more willing they will be to engage the process. These are decisions that need to be made, and I’m sure everyone is more comfortable if it is the development team providing these estimates as opposed to the executive team who doesn’t have the expertise required. In a perfect world we would know exactly how long every project would take, but this isn’t a perfect world so all we can do it work with what we have. At the end of the day we are all working towards the same goal, and as long as the development team and the business team understand the purpose as well as the limitations of the estimates, the more likely those goals will be achieved.