Adaptive planning, (in agile management,) is a continuous process throughout a project that can be used to make sure that risks are identified and updated. The flexibility this process creates reduces risk, delivers business value early and increases visibility. In this blog post, we’ll cover the main uses of adaptive planning, and how to do it correctly.
At project initiation, estimates are made at a high level to support investment analyses and are continually refined throughout the project. Estimation techniques are collaborative, so all stakeholders must be included in the process.
How we estimate during the Project initiation
Every project has uncertainty. No matter which Agile framework we choose, there will always be unpredictability – especially early in the game. Many organisations that are new to agile struggle with estimations, but if implemented the right way it’s all about clearing the air and emphasising Agile estimation and implementing improvements.
Estimation is undeniably the key part of Project initiation, but it has to be lightweight and effective. The usefulness of estimations has been recently debated, but for us, the value of this technique depends on how we propose them.
So here’s how we do it. Whenever you’re thinking of asking your team to estimate, be ready to clarify what decision the estimate is trying to infer. It’s also important to clearly explain the scope, cost and benefits of the decision. The moment your decision appears insignificant, it is clear that your estimates are pure numbers with no value in them.
Types of Planning assisted estimations based on client needs:
Estimation without proper planning and understanding may eventually jeopardise the entire project. These numbers are turned over to release plans, which are monitored on burndown charts. This becomes commitments that are tracked from time to time.
How we estimate during the project execution
It has been proven that to achieve a precise prediction during the course of your project you need to have the right estimations. There are several effective methods you can use during the planning of your project to correct flaws and improve estimations.
Planning Poker, a gamified technique for estimating, guides the team in correcting false precision and estimating quickly and accurately – all in a fun way. On the other hand, T-shirt sizing – sizing the tasks by shirt sizes like S, M, L, XL, and XXL instead of numbers – is widely used owing to its flexibility. However, for these estimation practices to work, we need to keenly revisit areas that are undermined during the estimation process.
Underestimating lists during estimations can lead to:
- Overlooking review and QA process
- Underestimating costs
- Missing integrated, UAT, and system testing requirements (any special testing)
- Capacity/availability management, support effort, retrospection, and review meeting
- Release, maintenance, and operation support
- Poor communication and team structure
Teams should be involved in a strong discovery, to collect important information and consider possible outcomes, before choosing an estimation algorithm. An estimation in
agile projects is a shared understanding of requirements and their solution collaborating towards success.
How to reduce uncertainties for increased accuracy
Agile is based on an empirical process approach. “Empirical” means “based on experiment or observation”. When you use an empirical process approach you accept that you don’t know everything about a project before you start. The process is designed in a way that enables you to learn as the project progresses, adapting both the solution and the process throughout.
The Cone of Uncertainty shows that project unknowns decrease with time. At the start of a project, comparatively little is known about the solution, so estimates are subject to uncertainty. It emphasises that initial estimates contain errors of the order of 400%. Even after the definition of the scope and the initial freezing of requirements, errors of the order of 30 to 50% are observed in the estimates. Furthermore, in waterfall approaches, the wrong estimates add up to changes in the environment and the team.
Uncertainty can never be eliminated from estimations – but it can be reduced. There are 6 ways we handle uncertainties in our Agile Projects:
- Break down the work: One measure to reduce the degree of uncertainty is to break down the work to reduce the size of the piece being estimated. The fewer elements that must be considered when producing an estimate, the more reliable the estimate is likely to be. We have refinement meetings during the Sprint to execute this.
- Having MVP thinking: MVP (minimum viable product) is essentially a choice to develop a new solution for early adopters first. It’s a simple powerful concept that quickly validates if we are moving in the right direction in terms of project success. Think big, start small, and learn fast – this is the minimum viable product proposition.
- Plan POCs: A POC is a set of efforts (a series of stories) aimed at achieving or validating a solution that has been planned. This should result in a small end-to-end demonstrable solution to ensure it’s feasible to deliver. Using this approach it’s possible to identify risks and opportunities upfront with less effort.
- Create Spikes: Spikes are a small, time-boxed, (single story,) effort used to decide and research future work. The results are usually a piece of knowledge that allows us to reduce uncertainties, write stories correctly and make the right decisions.
- Run PoCs (Proof of Concept): The purpose of a PoC is to validate an assumption that an idea, technology or approach is feasible, viable and applicable in practice. A PoC is best run as a small project with a clear scope and objectives. To support project aims, the PoC needs to be highly focused and completed quickly and to a high standard — without costing too much.
- Keep uncertainty visible: You must ensure that the hazards are sufficiently transparent because uncertainty carries a certain amount of danger. It’s simple to form initial presumptions and then allow those theories to come to pass.
- Prioritise with risk in mind: Although Agile methodologies will often suggest ordering the backlog based on delivered value to provide maximum benefit to customers, risk should also play a part in your prioritisation process. If there is uncertainty surrounding an item from your backlog, which could impact the project that you would qualify as big enough, then it should be considered a higher priority.
Effort estimation is not a plan, hence it sometimes is translated into a timeline. For example, how long does 50 hours of work take? It can be done in 50 hours, at about 60% probability – if I had precisely defined requirements that stay intact and worked on the tasks myself without any interruption whatsoever until I finish the work. How realistic do these conditions sound?
This is why effort estimation shouldn’t be interpreted as commitment and we need to be able to embrace changes and adapt quickly. Agile estimating helps us to uncover Potential Risks and open more dialogues within the team.
In summary, you can use the following tips to help you estimate effectively:
- Think about the estimating data you require. When selecting the appropriate estimating technique, consider the size and type of data you need. Dot Voting and Planning Poker, for instance, work well for projects with fewer estimation components.
- Identify the comfort level of the team. Take into account how well-suited each team member is to work in a group when selecting a technique. Teams that have never collaborated, for instance, may profit from Planning Poker, while experienced teams may benefit from other techniques or even no estimation.
- Try a variety of approaches. Find the agile estimation method that works best for you and your team by experimenting with a few different ones. Start with less involved strategies, like dot voting, and then think about attempting more involved strategies, like planning poker.
Did you like this post? Follow me now to see more posts like this.