Development projects succeed and fail based on how well the team can execute, test, and deploy the work items defined by the business. In Agile development, the full task list is defined based on the requirements documentation and stored as a Product Backlog – with batches of tasks/tickets assigned to Sprints as a Sprint Backlog. After each sprint the product owner is able to provide feedback on the progress and the development effort can be closely aligned on an ongoing basis with what the business is expecting. This approach is the great strength of the Agile model and it is clear how this approach brings benefits in any business where requirements evolve rapidly.
So at the core of running an Agile project is the ability to deliver Sprints successfully – if the development team can do this right from the start of the project then this will foster confidence in the product owner and the wider business. Too often though, sprints become over-ambitious, poorly defined or ambiguous and although the source of trouble often originates from business requirements, the development team can contribute to their own downfall during the Estimation process. If the team can really grapple the sprint definition and prove their estimates are sound with a high degree of confidence then we can see a higher percentage of successful sprint deliveries and happier product owners, as they see the overall product sticking closer to budget and timings. This article offers some pointers on how to improve estimation and therefore provide tighter control over sprints:
1) Estimate Conservatively
This may seem fairly obvious but developers tend to underestimate the distractions and inefficiencies that can impact on the actual work time on tasks. In many ways this entire list aims to address this point by highlighting all the reasons why a conservative estimate is often not as conservative as the developer thought.
When estimating, many developers think back to the most similar task they can recall, and remember the time taken, even applying a discount based on the experiences learned. Of course, we really need the developer to analyse, question and understand the current request rather than taking a previous item as a proxy.
There should be a contingency built in to every ticket to allow for: analysis time; time to ramp-up and ramp-down from each ticket; unavoidable inefficiency occurring during the working period; potential risk of technical issues arising; logging time and progress in the ticketing system.
2) Is the Ticket “Workable”
Encourage developers to push back on tickets that are poorly defined – never estimate the inestimable even when under duress. Be careful to distinguish between inherently flawed task requests (“build a chart tool” or “make sure all users only have access to what they should”…) and tasks that are temporarily unworkable (“please upload this file when I send it”). The tasks that are well defined but not possible to implement immediately are still possible to estimate. The flawed tickets are like a sickness to a product backlog – they can lurk in the background, failing to make it into a sprint but preventing the proper burndown on the project overall. It is the job of the PM / scrum-master to find and confront these items. But let’s assume we have a neat and tidy task at hand, with a clear test case, a good specification and a great chance of the developing getting it “Right First Time“. Let’s start the estimation.
3) Create the “Baseline” or “Happy Scenario” Estimate
This is the type of estimate that is well-intentioned but can be poorly thought-through, and without care can make it’s way into sprint-planning as a final estimate. In my approach, this estimate is just the baseline and the subsequent items need to be added to get this closer to reality. But starting here, you need the developer to imagine a completely uninterrupted timeslot where their IT equipment works perfectly and nobody is around to break their concentration. Make sure that the developer considers the QA they need to perform themselves, or the time taken to handover to the QA team. Ideally the developer will formulate a test case at analysis phase and perform this unit test themselves before marking the ticket as ready for testing in the ticket system. If the ticket turns out exactly as hoped then this is our best case scenario – let’s say for our ticket this is 1 hour.
4) Benchmark or Cross-Reference Estimates – “Planning Poker”
For increased comfort level on the precision of our estimate, arrange for multiple developers to estimate the same ticket and take the mean or modal average. If they are wildly different estimates, why? Maybe this reveals a flaw in the design of the development task. Maybe it shows the developers have differing ability levels, or just a more cautious/ cavalier approach – all of which needs to be considered by the PM. Below we look at the analysis time required in more detail. Often the PM is reluctant to double or treble that time by cross-referencing the estimates in full – so a great, low overhead, Agile approach is Planning Poker. In this game, developers hold cards with a number of different estimates (1hr, 2hr, 4hrs, 1 day, 2 days, whatever) – and when the task is shown they are asked to play the card they think is closest to the estimate. This means they are unable to influence each other and the PM gets a good insight into the nature of the estimate. If they are all the same then the PM can be confident the estimate should be accurate. If they are very different then the ticket is flawed or the developers have reached different understandings of the task. This can even work for non-colocated Agile teams by running the session online at http://www.planningpoker.com.
5) Allow Properly for Analysis Time
Analysis time is the time taken for the developer to review the task, confirm they understand it, request clarifications and then formulate a plan of attack. When this is done it should be possible to create an estimate. Analysis time happens in two phases: the first being during the estimation and the second is more in-depth, occurring when the work is undertaken. Project managers need to make a trade-off between taking a long time to fully analyse up-front and produce precise estimates, and the risk of “ballparking” the estimates and potentially adding extra analysis time at the start of each task, or carrying the risk of estimates with poor accuracy. Every project is different and the project manager (or Scrum-master) should choose a balance here that gives them the level of comfort about estimation accuracy that they need. Of course, it is important that this is communicated clearly so the developer knows what they are being asked to do - if they are asked for ballparks it must be clear that they are accountable for mis-estimation to a much lesser degree than if very precise estimates are requested.
The total analysis time is proportional to the complexity of the ticket, and will vary depending on the precision required – if you can live with a 80% chance that the time logged will be within +/- 5% of the estimate then there is little overhead to the analysis time, but you will pay it back in the mis-estimations, depending how lucky you get. If you need 95% chance that the time-logged and the estimate will match-up then there is a much more considerable investment in the analysis time. As a yardstick, you could 5% for quick and dirty analysis and 10% for more precise analysis (so add 3 mins or 6 mins to a 1 hour task).
6) Acknowledge, Understand (and tackle) the Team’s Avoidable/Unavoidable Inefficiency
Every team and every individual has inefficiency – this is not a bad thing per se, it is just an acknowledgement that there are many sources of background noise and distraction that can slow down a person’s work. Inefficiency is avoidable or unavoidable though, and it is important that a good development team has a good awareness of both and takes steps to tackle them or at least acknowledge them in their estimation.
Avoidable inefficiency is the kind of issue that has to be tackled through better management of people and can include: tardiness; lack of focus; lack of knowledge; being too easily distracted by others, even when done with good intention; attending to personal issues at work. Nobody is perfect and there is always likely to be some waste of time in everyone’s day – you can’t always control when you may get a phone call from home, or when the train is late. So make some small allowance for this and as a side-project you can aim to reduce it. Every team is different of course, but if you find there are developers losing 30 mins or more in a day to these kind of issues – this reduces their efficiency to 93% – on a regular basis, then the alarm bells should be ringing.
Unavoidable inefficiency is a term that can cause some debate – I just mean Unavoidable in the sense that this is a distraction that arises naturally from within a person’s job role, or due to the nature of the business. Being a good project manager is all about making the Unavoidable Avoidable, but tackling these issues is definitely a longer term challenge. To provide some examples, we could consider that a developer may be taken away from their task by a critical bug on another system or part of the system; or another developer may want to pick their brains for a solution to another problem in an informal way; or they may need to attend an ad-hoc announcement from the company; or just staying on top of their email backlog; and from a health, safety and sanity perspective developers should remember to step away from their workstations periodically to give their body and brain a break. Be careful here that we are not including known interruptions – such as the weekly company meeting, or lunch breaks - this time must be subtracted from the plan, and not double-counted into the inefficiency factor.
In the unavoidable inefficiency I usually find it sensible to subtract an hour per day from each developer’s schedule. With all this taken into account, it is sensible to have an extra 10-20% on any estimate to allow for these inefficiencies. If we take the middle ground then we have added 9 mins to our one hour estimate.
7) Assess and Allow for the Technicality of the Task
The PM really needs the developer to incorporate the possibility that, despite best efforts to analyse the task and provide a good baseline estimate, they find out mid-task that they hit a technical barrier. These barriers could relate to infrastructure, licencing or purely to the coding, but they represent show-stoppers from the developer perspective. At this point the developer has to limit the amount of time take to “force” the issue – this is the time they spend re-writing code or attempting a different approach. The last thing a scrum-master wants to hear at the daily scrum is that the developer was working on a one-hour task the previous morning then spent 7 hours looking for a work-around and hasn’t solved it. The developer should spend no more than 25-50% of the ticket estimate trying to resolve the issue, if the issue is within their domain – if the issue is outside their domain then they should stop immediately. This is where the scrum master steps in and escalates the problem to the relevant group to ensure a speedy resolution.
To add some sort of factor to our calculation, we need to consider both the percentage of tickets suffering from this phenomenon and the average time cost. Fortunately this should be a rare occurence, but when it hits, it can hit hard. I would suggest that only 5% of all tickets should hit a barrier like this – if an organisation has a higher incidence then the boundary parameters need to be analysed, possibly in the infrastructure or the developers themselves, if they are constantly having to amend their approach. When a ticket hits a barrier the effects can be severe – I have seen work items take up to 5000% of their original estimate and there must be more severe occurrences out there. Often the developer has to take out a snippet of code or change a class, and it works out taking 50% longer than estimated. For our example we can assume that the average barrier causes the estimate to double – so we take a 5% incidence and multiply by 100% of the estimate. This means it would be sensible to add 3 mins on to our one hour ticket (and all tickets) just to give us the contingency we need.
8) Allow for the Proper Recording and Documentation of the Task
It is always extremely important to properly record the progress and final outcome of the task being worked on. Whichever issue tracking platform you use, there is a time required for the developer to provide commentary on the task, log the time taken and generally update the ticket. You may also encourage them to provide labelling on source control check-ins and also check-in T-SQL scripts into source control or append to the tickets. Although this creates overhead, it does show a development team in control of the issues being worked on, and provides continuity should one developer need to pick up another developer’s work, as well as an audit trail of what has been done.
For a 1-hour task, a developer might spend 2-3 minutes updating the ticket system, logging their time spent and doing any other tasks relating to the closure of the ticket. This type of overhead can often be overlooked – meaning developers rush this and the quality of information in the ticket system suffers because of it.
9) Ramp-Up and Ramp-Down Time
In between tasks there are a number of things that happen while the developer is reaching full productivity. First of all the human brain takes a short while to get fully concentrated on the task, especially if the current one is very different from the last – and at the end of the task it takes a little time to re-focus on the “real-world” tasks such as updating the ticket system and preparing for the next task. On top of this, the developer must prepare their tools – perhaps moving between visual studio and sql ms, or accessing a remote server. Hopefully these issues are minimised by ensuring the business is providing the developers with easy access to systems and high-quality tools for the job. For a simple one-hour task, we only need to add a minute (approx 2%) to the start and end of the curve to alow for this.
So our simple 1 hour estimate has acquired an extra 23 mins due to factors that may be invisible to a PM who is just blindly accepting happy scenario estimates. In a 40 hour sprint the team would only achieve 29 tickets instead of 40 baseline tickets. This is valuable information when it comes to finalising the estimates and defining the sprint backlog – there are in fact two options at this stage: include the extra overhead within each estimate and record our 1 hour estimate as 1hr 23min; or record the estimate as 1hr and incorporate the 23min into a “buffer” of overhead within the sprint (so either 29 tickets that completely fill the 40 hour window, or 29 hours of tickets and 11 hours to cover overhead). The PM must ensure that one (and only one!) of these options is taken – if they double-count then the team would attempt 21 tickets at 1h23 and also set aside 11 hours of overhead, leading to an underachieving sprint.
I hope developers and PM’s might benefit from considering the items on the list and how they influence the estimation process. Mis-estimation is one of the leading reasons for failed or unsatisfactory sprint deliveries, and confronting the challenges here should lead to tighter estimates and some deeper insight into productivity at a developer, team and organisational level. In the next post I will look in more detail at the composition of a sprint and how we can formulate a backlog that the team can be confident of delivering and demonstrates to the business that great progress is being made.
