An Agile Playbook: Play 3 - Planning
?<<< Previous Chapter ------------------------------------ Next Chapter >>>
Working software is the primary measure of progress. - Principles behind the Agile Manifesto
In classical projects, there is a target to achieve.? The project is created to achieve that target.? A team is then built around the project.? The team and the goal are then used to derive a timeline or schedule.? The primary focus is generally scope - the original goal.? If a classical project is split into milestones, these will similarly be built around a specific scope.
The classical project environment is complicated, not complex.? As a reminder, a complicated problem is one which consists of many parts which interrelate in a predictable manner, like a clockwork mechanism. In a complex system, the interaction of elements results in an unpredictable behaviour.?
In a classical project it is viable to deconstruct the problem to find all of the tasks and activities required to achieve the goal.? These define the scope for each milestone and the total project.? By assigning a team and estimating the work in the tasks, we can predict a timeline.? With a classical project we then schedule each individual task on the timeline and predict when each task will start and finish.
If we are to work in an Agile way, we need to approach planning and tracking differently.? Development is seen as a continuous process.? It is not split into projects which start and stop.? As part of its continuous nature, the teams are expected to be fixed and stable, not created for individual projects.
As a result, Agile development tends to work in fixed timeframes or “timeboxes”.? Typically there will be a release point for which the date is communicated well in advance.? This is typically a requirement for customer expectations and is part of building a roadmap for the product.? The steps on the way are not milestones with fixed functionality, but are reference points with fixed schedule. This allows flexibility for learning and change.
It is very important to defer public commitment to exactly which features will be in the product, because this makes it possible to reliably release the product on time. The release date is guaranteed, but the exact features are not. - “Leading Lean Software Development” Mary Poppendieck
Few topics in planning with development teams are more controversial than estimation.? We know we are working in a complex environment.? Software development is not wholly predictable nor will ever become so.? There will always be a component of development which is emergent and discovered as the work progresses.?
People misunderstand estimation as being prediction.? Stakeholders can place too much confidence on poorly communicated predictions.? Developers, perhaps bitten by this in the past, can be reluctant to generate any numbers knowing that these will not accurately foretell the future.
Estimation is not prediction
Agile development works best with fixed schedule points and a flexibility in scope which is delivered.? By ordering and prioritising backlog we can “steer” the work to deliver the most value by the point it is released.? In that context, let us consider how best to use estimation.
Let us first be clear what we mean by estimation.? Like many areas it is important to standardise the language.? Estimation is the sizing of individual pieces of work.? Here the sizing of product backlog items.? When a team are estimating a piece of work, they are judging how large and complex it is.? They are not saying anything about when it will be done.
Estimation is not scheduling.
Colloquially we might talk about “estimating when we will release”.? I advise you use the term “Planning” whenever you are talking about a schedule.? Size of work is (only) one component part of a plan.? Estimation does not directly tell you when the work will be done.? We also need to know how much effort the team will put into the item.? And we need to know where it is on the priority list.? In general estimation is sizing at the task level, planning is deciding what actions we will undertake as a result of that (and other) data.
Estimation often seems to be a source of tension.? Given that, why do we bother doing it?? Of course ignoring it simply to avoid conflict is not a good solution.? But it is important instead to consider the value estimation brings and the areas of conflict, and then consider the best way to apply it.? If the right answer for your organization is not to estimate, that is also an option in some cases.
The first and most obvious benefit from estimation is to gain some ability for prediction.? In Agile development we are working with fixed timeboxes which represent a release point or equivalent.? We would like to understand what we may be able to achieve within that timebox.? In classical project management we would plan out a detailed schedule of work.? In a complex agile environment we lack the stability to do that.? We are looking instead for a flexible approach which can cope with constant reordering and change.? Having an idea of size of elements gives us lightweight guidance on what is realistic which we can continually update as we learn.
Optimism is an occupational hazard of programming: feedback is the treatment. - Kent Beck
The second value we see from estimation is in ordering the backlog.? It is important that we maintain an ordered backlog to represent the work.? But we cannot order based only on value.? We need to understand the trade-offs involved in work items.? A medium value, low effort piece of work may well be higher on the list than a high value, high effort piece.? A “cost of delay” measure could be used involving how much value will be delivered, along with the delay from its size and position on the backlog.? These assessments require at least a loose understanding of sizing.
The final value from estimation is perhaps less often considered. ?The process of estimation itself has an inherent value.? When people consider the size of a piece of work, they assess what is involved in the work.? To do this, the work needs to be well enough defined for a level of clarity.? I have often worked with teams using Estimation Poker?(or Planning Poker?) sessions to look at work items.? In this approach, each team member generates an independent estimate.? The technique is designed to ensure that these are “blind” and not influenced but the opinion of others.? One repeating experience is that there can be a wide spread of numbers because different individuals interpret the scope in different ways.? The estimation process forces a discussion.
领英推荐
There are balancing factors to the obvious benefits to estimation.? There is a risk that estimation can itself push teams down a non-Agile route.? If the work is estimated it may appear more predictable, although of course assigning a value does not truly make it less complex.? If this happens, we could potentially deprioritise the agile approaches that we need to manage the high levels of change and uncertainty.? By perceiving the project as more subject to decomposition we could shift towards applying reductionist thinking.? This can lead us to viewing the backlog not as guidance of our current best thinking but as a predictive fixed scope of work.? And if we misunderstand that, we are setting a fixed scope, not a fixed timebox.? Or fixing both and having no remaining flexibility.
A second argument often used against estimation is that it stresses teams.?
Asking teams to estimate how long their work will take (or how many points they will deliver in a Sprint) has connotations that their output is being measured by an external party (manager), creating an environment of fear - Neil Killick
Although I understand the concern, I have some issues with this viewpoint.? This criticism doesn’t relate to estimation as much as to planning.? It is the commitment being made to a specific plan or date which causes stress.? This issue would apply to abuse of any planning involvement by the team.? And yet surely the answer is not to avoid involving the team.? That is simply a step to disempowerment.? This issue exposes poor management style and lack of trust.? This is more about psychological safety than estimation.? It is best addressed by addressing psychological safety and realistic plans.
Can we avoid estimation entirely?? We should remember that estimates require effort.? That effort does not go into the delivered product.? Therefore in Lean terms, it is “waste”.? There is always validity in challenging waste effort. We must remember it may be a requirement at our state of maturity - we cannot yet make bananas without skins.?
We might sometimes avoid the "waste" of estimation.?
The #NoEstimates movement has been vocal on the subject of removing estimation.? With an ordered backlog, you work through the work in priority order.? The movement suggests you can do this successfully without any need to estimate work.? Woody Zuill has argued that it is better to focus on showing the customer progress than to spend time on predicting an end point.? An Agile key value is “working software” and giving your customers real value as soon as possible is most critical.? Forced into a choice between making progress and building a better plan, I’d certainly agree on the former.? And in some cases, flowing new value rapidly is enough.
Unfortunately this feels it often isn't the case. ?Customers and internal stakeholders still want some level of prediction.? We can give the customers a release date.? Because of timeboxing, that is of course the easy part.? We generally also need to give stakeholders a good idea of likely content to make the best informed decisions.
With an ordered backlog, the further down the backlog you go, the more uncertainty you introduce.? Future work is less well defined and more subject to change.?
The purpose of estimation is to balance risk and commitment.?
This guides the amount of investment you will need in estimation. The more you are able to deliver continuously the less you will need to rely on estimation.? The more that you commit to what will be in a timebox, the more work goes into estimation.
All work at the top of the backlog should be the right size for the team to start work.? An analogy is breaking the "back logs" down into kindling.? If we work in iterations, this means that work should be small enough to be confident of finishing the bulk of what we plan in an iteration.? Imagine we have a ten day iteration and our backlog items take six elapsed days assuming the expected number of team members involved.? We can complete one, but will potentially end up with significant unfinished work.
In general we should aim for work items to be refined to below half an iteration in schedule to complete.? Ideally a quarter of an iteration would be a good target.? That would mean 3 days for a ten day Sprint or 1 day for a five day sprint.? This work decomposition is one area which makes the smaller Sprint sizes more of a challenge for inexperienced teams.
We keep the work items to a short schedule by breaking them down into their component parts.? Breaking backlog items down is often called “rightsizing”.? The value of rightsizing to make work ready to be started is clear.? Before you start an iteration you need the work to be small enough to fit cleanly in the iteration.
The more you rightsize work, the less critical estimation becomes as a tool.?
Estimation is a tool whose purpose is to allow you to manage items of different size.? If work items are all similar in size, you can track by simply counting work items.? This approach fits well with the ideas in the domain of Lean.? In manufacturing, of course, elements being manufactured are intentionally identical.? Many of Lean’s preferred metrics focus on assumed-identical items.? In a fully “rightsized” system you could count items and look at how fast they are produced.?
We can measure how long things take, in “cycle time”, and use that to make such predictions as are necessary. - Ron Jeffreys
Rightsizing can in principle lead to significant efficiency gains.? It can potentially lead to removing a need for estimation as an overhead.? Although this has been successfully applied by many teams, there is a word of caution.? A team needs to be skilled and experienced to make rightsizing work.? For most teams, backlog items will be of different sizes.?
To make a rightsizing approach work you would need to equally break down everything as far as you need to predict.? That would be a significant up-front investment in backlog refinement.? Most teams would find this a challenge.
About Jay Alphey
I have built and led technology groups in multiple high growth scaling organisations, working across the organization to coach teams and develop and scale the structures and practices which allow the teams to thrive and achieve repeatable delivery of business value.
I am available for both consulting and full-time VP Engineering/Operations roles in Cambridge and London.