An Epic Software Estimation: giving continuous insight in large projects
In this blog post, we explore the invaluable practice of continuous insight into delivery capacity, and how it can be a game-changer when it comes to keeping your stakeholders happy. We delve into the why, the how, and offer practical tips to help you and your team master the art of software or project estimation. So, let’s embark on a journey to unlock the secrets of effective project estimation and the impact it can have on your organization’s success.
Introduction
A few months ago, a product owner in our team knocked on my door. He was anxious about an upcoming meeting where he, other product owners, and some C-level stakeholders discuss our roadmap’s current status. In these meetings, having project durations is crucial, and he needed to provide a rough estimate for our project’s duration.
Recalling that a colleague and dear friend had developed a template for tracking epic durations based on estimations, I reassured our product owner: “Let me assist you with that. I’ll call for a team meeting next week, and by the end of it, I can give you an estimation how long this project will take.” PO: “That would be awesome.”
Well… time to figure out how to actually do this.
Why software estimations?
What is an epic? An epic is essentially a feature that is too large to be contained in a single user story. Therefore an epic is cut-up into multiple, more manageable, user stories. The term epic is often also used for grouping many user stories. This is because tools like JIRA refer to an epic as a bunch of tasks, user stories, etc. Just know, in this blog post, I use epics to describe a project that is so big, it takes multiple sprints to complete.
Enough about definitions. What brings an estimation to us? In the words of Steve McConnell: “An estimation gives us the ability to commit to a delivery and control the project to meet its targets”. This quote comes from “Software Estimation: Demystifying the Black Art”, a book that has greatly impacted this blog and my view on software estimation. In this quote, “control” can be read as the decisions we make based on events that have an impact on the project’s duration and quality. In the context of this blog, estimation revolves around how long it will take to deliver a certain part of functionality. The ability to address the question “What do we need to finish this project in the time we would like it to take?” gives a great perspective on the decisions you make.
While the “target” of a project is important for the business, that doesn’t mean it is achievable. The target is a description of a desirable business objective. The “commitment” is a promise by the team to deliver a set of functionality by a certain date. The commitment can be more aggressive or less aggressive than the estimate. An estimate merely helps you get control over a project. It can help you make decisions about the path of the project, and help you get a clear view of how certain events impact your project.
Don’t be afraid to estimate epics
More often than not, we shy away from estimating projects with a large scope. The uncertainty that comes with a large project makes it hard to estimate precisely. This is a wrong way of viewing estimations. As mentioned before, we don’t want a precise calculation of how much a project costs. We want insights so that we can exert control over a project. An estimation is something you work on during the entire duration of the project. A feedback loop in which you keep track of your estimation gives great insight into your project. It gives control over the project because you can see the impact of decisions you make.
How to make a software estimation?
When working on a project with a defined set of requirements, I think the best way to start estimating epics is by using relative estimations. Quite possibly, it is not the first epic your team works on (and hopefully not the last!!). That’s great! That gives us a reference point to what the new epic can relate to. So say, for example, you want to estimate epic C after already completing epic A & B.
A common way to start estimating is by relating to the size of the epic to a T-shirt size. This would look something like this:
Simple for A & B, because they are already done. Epic C can be estimated relative to A and B. This process is pretty straightforward. Knowing that C is larger than B and somewhat smaller than A, we can classify C as a size L.
The estimation gets even more useful when we look back on how much story points it cost us to complete A and B. Say it was 150 points for A and 50 for B. That gives us a range to roughly calculate the size of epic C. For some projects, roughly knowing the size of your epic and the time you need to spend on it is enough. In that case, you can stop the project estimation at this point.
As mentioned before, we are not measuring the exact size of the epic. We are merely estimating how long it takes to complete. When you know the velocity of the team and the rough boundaries of the estimation, you have enough information to make a software estimation. We can communicate the size of the epic with stakeholders and see the impact on the duration of the project based on the decisions we make.
From a rough to a specific software estimation
However, I don’t think you should stop there. Because after meeting with the project team once more, you can assign specific story points to epic C, based on previous experiences of epics A and B, and possible complexity.
This is the best scenario! Because now, it’s even possible to track the progress of the epic, based on the initial estimation. After completing or assigning story points to a user story, you can subtract those points from the 110 we estimated it would cost us to complete epic C. This is helpful for a number of reasons:
First off, it helps the team focus. If your main goal is to complete epic C, we should see a steady decrease in the amount of points left in the epic. If this is not the case, it is a great moment to ask yourself, the team, and perhaps the product owner: “What’s going on? What is preventing us from completing this epic?” So, it gives us a great tool to control the project.
Estimating an epic is also super helpful for timely communication to a stakeholder. Say, after a few months’ work, epic C is left with 40 points. But the team knows there is still much more work to be done. This information is fed through the feedback loop of adjusting your estimation based on new knowledge, which means you can communicate this new estimation to the stakeholders, who can choose to assert control or not. People tend to show greater understanding when you inform them in advance that a feature will take longer, instead of waiting until the expected delivery date.
So, you get a lot by taking a bit more time to estimate your epic and continuously communicating about it.
Tips
One of the tools I like is the use of milestones. Sometimes it is hard for your team to estimate a whole epic. Even if you have relative epics to relate to. I like to cut the epic into milestones and estimate those individually. In our project, we work towards a minimal viable product (mvp) which is milestone 1. After completing that, we will integrate it; milestone 2, and so on. It gives the team a better overview of the work they need to do.
Another tip is to try not to get too fixed on the estimation or story points you initially gave your project. Projects change, whether it’s features that come up halfway through the project or some complexity you didn’t foresee. Just make sure you review the estimation from time to time. When you feel like the work it takes to complete the project doesn’t align with the plan, estimate again and let stakeholders know.
Our project
Back to the beginning of this blog post: the promise I made to my product owner. We had a team meeting, and within an hour or so we had a decent idea of what our estimation for this project was. The milestones gave the product owner a tool to communicate the work that needed to be done and what our estimation was based on, giving them more control over the project. So far, we are still on course for our project, but last sprint we saw we needed to include some more stories relating to the epic to keep on track. It has truly helped tracking our progress and adjust the planning when needed.
So, give it a try. Call for a team meeting and estimate your epic! If you have any questions, please feel free to reach out to me.
