No items found.
One of the most core components of the product management process is estimating the upcoming work. Based on this a product owner will be able to rank stories, calculate potential ROI or plan releases. There are multiple ways in which we can estimate and multiple unit of measure, however we need to always remember that an estimate is just this – an estimate and no matter how technically proficient a team is or for how long they’ve been working on the same product an estimate can be way off due to all the unknown involved. I’ve seen cases in which senior developers estimated a specific piece of work to take no more than three development days (actual estimate given by a technical architect for a simple API integration after a brief technical review of the 3rd party API) and the actual work was completed after more than three months (due to the fact that some endpoints only returned dummy data and there was no actual functionality behind them). I’ve also seen cases in which developers have been ultraconservative and gave a two month estimate but found a faster way and completed the work in less than a week. I know these are extreme cases and most estimates will be met within a small margin of error, however they still show that there can be cases in which very senior team members that are part of established teams can be provide highly inaccurate estimates.
With this in mind I will go over a few ways in which teams can estimate as well as the most common units of measure for estimates.
The most simple way of estimating development work is for the product owner or stakeholder to literally ask a developer or a team’s lead developer for an estimate on how long would it take to deliver a specific piece of work. This is very common in start ups or organisations with little or no process in place and it’s very rarely the case in which the developer will be able to provide an accurate estimate. This is due usually to the high levels of unknowns as well as short time given to provide the estimate. Bluntly this type of estimates are highly unreliable in should be used as a last resort for small stories that are fully defined (e.g. changing the colour of a button). I personally never encourage this practice and I advise developers not to provide estimates without a proper assessment of the work.
Next method of estimation is to get the team together and ask the development lead or the developer that will pick up the work to provide an estimate for specific piece of work. This way the rest of the team can provide feedback regarding the estimate and advise on possible unknowns. They also have a chance to ask questions and raise concerns. The estimate provided through this method, although more accurate relies on each developer providing input. I’ve encountered instances in which developers are very introvert and you literally have to name them to provide their feedback.
A better method, and one I usually recommend is planning poker sessions (face to face or virtual). This is where the team gets together and the product manager explains what he wants to achieve, the reasoning behind the feature as well as the acceptance criteria and the each of the team member uses a deck of cards (or virtual tool) to give an estimate. After each team member gave an estimate (usually all estimates are given at the same time to avoid bias) the ones that gave the lowest and highest estimate explain the reasoning behind it and the team votes again. This process repeats until the team reaches consensus. This is by far the process that provides the best accuracy because it gets everyone engaged and encourages collaboration. Through this process the estimate is owned by the whole team and it’s up to everyone to deliver on their commitment and up to the product manager and scrum master to provide the means and guidance to do so. This process works best in teams with higher head count and is the one that requires the highest amount of time. I’ve seen over time that on average estimating a single story can take around 30 minutes.
Since until now we explored how teams estimate it’s time to see what different teams use as unit of measure for their estimates. I will cover the most common three units and I will start with time.
The most simple unit of measure is time – common, easy to understand and universally valid. Commonly teams use as a smallest unit one developer day, however I’ve seen some teams using half days as their smallest increment. Time estimates are used most commonly in agency type companies where they bill customers directly for the work that will be done, however these are not out of place in the fintech and banking industry (and in general in some of the more traditional and regulated organisations). Using this enable even the most untrained stakeholder to grasp the concept and to calculate cost (time estimate multiplied by cost).
The second unit is size estimate (most commonly called t-shirt sizing) and it’s usually represented through clothing sizes: XS, S, M, L, XL. Compared to the first unit that it’s absolute this usually represents a range (e.g. a M size story could be something that would take between three and five development days). It’s important to remember that the team has to decide on what each measure mean however once decided they have to stick with it throughout the teams/ project life. In order to estimate using this sizing unit teams chose a story they feel is the smallest, assign that a XS measure and estimate the others based on this baseline. The story used first will become the reference also for future estimations.
The most complex concept I want to cover in this post are story points. These are commonly used in agile environments in scale up companies however they’ve seen a gain in popularity and are now common in established companies with an agile culture. The most important thing to note about them is that they always measure the complexity of a story and not direct time. Story points can be used to estimate together with velocity (how many story points a team completes in a sprint) as well as volatility (how much do story points vary between sprints). This work best in conjunction with planning poker sessions and if used properly can be very sharp tool in the arsenal of every product manager.
This article’s aim is to be just a brief intro into the world of estimates and I would like to close with a few conclusions:
- Always use the same unit of measure for your stories, be consistent.
- You an alternate the type of estimation sessions you use based on the stories you need estimated and on what works best for your team.
- Although story points are the hip new thing, time might work best in some organisations.
- If a company already uses a unit of measure don’t try to change unless good reason – change for the sake of change isn’t good.
- Some stories like investigations don’t have an estimate but are timeboxed.
- In order to get the best results slice the work in the smallest workable items.
- An estimate is just this – an estimate.
This post has been published on www.productschool.com communities.
By : Cosmin Elefterescu
