Ahh, estimating. We all hate to do it, but it’s critical when releasing more often. The good news is it’s not nearly as important to get it “just right” for an entire effort, but it is important that the current sprint is estimated well. The following article should help you understand what’s different about estimating a sprint (release) when you use Continuous Delivery as apposed to using a SCRUM/Agile process where the work is done in small iterations but not actually released.
Because delivering IT assets is a highly variable process (if it weren’t every task would take the same time just like creating parts on an assembly line), it is highly likely that one or more estimates will be off by some amount. When your team starts a sprint of work using Continuous Delivery, the goal is to actually release something at the end. Because of this focus, we need a way to accommodate variability.
The problem with “buffers” in tasks
Most folks remedy variability by putting “buffer time” into their estimates to account for unknowns. If you put buffers into tasks, there are two problems that occur. The first is that psychologically, those assigned to the tasks have a misplaced sense of “extra time” left to complete their tasks. You do not want individual tasks to be scheduled to take any longer than what’s expected. If your team doesn’t understand a user story well enough to describe verifiable acceptance criteria to demonstrate it works, don’t put it in the sprint! If you do this, you are making it highly likely that you won’t release at the end.
The second problem with putting buffers into individual tasks is that you have just scheduled all of your tasks to essentially be as costly as they can be. You can’t track to a realistic estimate and are essentially planning on each task taking as long as possible. I can’t stress this enough – don’t use buffers in task estimates for sprints when you want to release the work at the end.
Why high capacity utilization is dangerous
Because the goal of most IT value chains is to deliver value as efficiently as possible, it can be tempting to load resources to high capacity utilization. Because we don’t want buffers in our tasks but the work is highly variable, the proper place to accommodate this is by scheduling resources with excess capacity. By leaving excess capacity, resources that finish tasks early are freed up to help others with theirs and it is more likely that having multiple people working on a problem will still get it finished on time than asking a single, highly utilized resource to “just work faster”. The risk of any one member blocking the entire release by variability encountered in getting their task done goes up exponentially as you pass 70% utilization. If you don’t leave extra capacity for resources, you are all but ensuring that you will not be able to release the work at the end.
The first sprint of an effort that will employ automated continuous releases is the place to estimate and complete tasks that are hard to do once the entire team has started work. The following is a list of some things to consider scheduling for the first sprint (or several depending on the size of the effort to be worked on) to prepare for the entire team coming on board.
- Time to setup infrastructure like servers, security accounts, and opening of ports
- Time to setup source control for any change controlled assets
- Time to build an initial website, database, business intelligence data mart, mobile application, or whatever you will be delivering that is either empty or has just one page or set of data
- Time to create an automated deployment process for deploying changes through your various environments (development, UAT, production etc.)
- Time to create a policy for who will approve release candidates to be promoted from one environment to another
- Time to populate and prioritize the backlog and do business analysis necessary for agreeing on the acceptance criteria for the first sprint where the team will work on functional deliverables
Once the larger effort gets underway and the team is brought in, the list below includes some things you should consider when estimating work that will be released at the end of the sprint. This is by no means a comprehensive list but includes some things you might normally put off until the end of a larger “iterative waterfall” project where the team builds functionality in sprints but doesn’t release it until a stabilization phase at the end.
- Time to implement new features or changes
- Time to test features or changes
- Time to fix any defects found during testing
- Time to change anything about the automated deployment or testing process needed to support the features being delivered
- Time to update user documentation that describes the new features or changes
- Time to hold the sprint review meeting, accommodate feedback, and release to production
- Time to hold a sprint retrospective to capture what went well and what actions will be taken to remedy problems found
Hopefully this article helps you to consider some of the changes needed when estimating work to release more frequently. The team will complete less functional volume than you might be used to, but the trade-off is that at the end – you can release it. As a parallel effort to the ongoing sprints of releasing new IT offering functionality, Product Management can work with early adopters of the new system or customers to integrate their feedback into the backlog to make adjustments keeping the team’s efforts in line with their needs.