-
Notifications
You must be signed in to change notification settings - Fork 85
Time Estimation
This document describes our approach to time estimates, and exists to create clarity around why we do time estimates, what we want to get out of the practice, and how we will do it.
Trust between engineering and stakeholders - One role time estimation plays in agile is to create two-way trust by managing stakeholder expectations, defending the engineering team from unreasonable speed/volume demands, and building trust that an engineering team will follow through on its commitments to other stakeholders. It doesn’t seem like this is necessary in our case, since we’re all pretty close to the problem.
Creating individual pressure to get more done - If there’s pressure to complete a certain number of points, that creates incentives that distort the measurement. We can still have the shared goal of being able to complete more complex tasks quickly, and this can help us measure how we’re doing.
Improving communication - Time estimation can reveal differences in our individual understanding of scope. If one of us sees a 1 point issue, and another sees a 3 point issue, maybe one of us is just missing something, but maybe we’re understanding the feature differently.
Limiting scope - It’s always good to reduce scope when we can. If one of us sees a 1 point issue and others see a 3 point issue, maybe there is an actual scope reduction possible.
Choosing issues for leverage - Unless an issue is a total dealbreaker, we can think about leverage: how much value does the issue bring for a given amount of work? Estimation can show us what issues have high or low leverage.
(Another way to find high leverage issues that doesn’t require up-front estimation is to spend a set amount of time picking low-hanging fruit, like 2 days/month.)
Handling unexpected difficulty - Some issues may turn out to be much harder (lower leverage) than expected. Estimation gives us a threshold trigger for having a discussion about what to do. Should we change our approach? Limit scope? Abandon the issue?
Short-term time estimation - If we keep track of past performance, we can get a rough sense of how issue points correspond to days and weeks, so we can have some basis for estimating time on issues we have planned and estimated.
Long-term time estimation - We can also estimate sprints and epics on a point scale. If we keep track of past performance, we can get a rough sense of how long it will take to do something based on issue points.
Spotting time-sucks - Maybe tracking actual time spent on an issue, in contrast to estimated time, will help us identify time-sucks, especially ones we don’t expect.
What we estimate - We can estimate individual issues but also epics and, at some point, “themes” (groups of epics that correspond to some strategic goal, like iOS notifications). Let’s start with issues and epics. Some systems don’t estimate bugs, but I think we should, so that we can see how much work we’re putting into them.
How we estimate: Fibonacci difficulty estimates - Trying to make points correspond to days will get distorted by changes in the team and will obscure improvement or regression, since our estimates will only reflect our team’s speed at a given moment. Instead base estimates on complexity, effort, risk, and dependencies / external factors.
- Complexity: How intellectually challenging is the task?
- Effort: How much work is required to complete the task?
- Risk: What uncertainties or potential obstacles could affect completion?
- Dependencies: Does the task rely on other tasks or external factors?
Here’s a sample scale:
- 1: A very simple, straightforward task with minimal complexity and little to no dependencies. This could involve a minor change or a small bug fix.
- 2: Still a simple task, but slightly more involved than a '1'. Might include a couple of minor dependencies or a bit more complexity.
- 3: A moderate task with some complexity, likely involving multiple steps or coordination with others but not overwhelming.
- 5: A complex task that requires significant effort and possibly coordination across team members. This might involve integrating multiple components or dealing with some uncertainties.
- 8: A very complex task that could have major implications on the project, involve multiple areas of the system, and have considerable unknowns or dependencies.
Epics should be estimated on their own 1, 2, 3, 5, 8 scale.
We can introduce 16’s if we want to, but we should try to break up any items that are 8 or more.
- Make a set of reference issues for each point level.
When we estimate - We can estimate epics and issues when planning a sprint. Ideally we come to agreement on estimates (helps with communication and scope limitation) so we should do this together. We can try “planning poker” (estimating on our own) or “snake” (rotating who estimates first, then discussing) but eventually we may just have people estimate individually or in pairs outside of meeting times.
Where we estimate - Our Github issues now has a field for point estimates. (It doesn’t enforce fibonacci values, but we can.)
Tracking actuals - At the end of the sprint we can track actuals in a spreadsheet. (And also for epics when we complete them.)
Tracking bugs - We can track work spent on bugs in the same spreadsheet or in a different one. We should also categorize bugs over time so that we know where they are happening. We do not have to track bugs that are generated by work in the current sprint.