Managing the project in Scrum like environment may have numerous challenges. They may be related to Scrum framework implementation, team communication, workload management or customer relationship management and many more.
In every project, no matter of philosophy, methodology or framework utilized uncertainty, risks, impediments are something embedded and to be overcome. That is why there is an element in every project that can be called ‘weather’. Let’s take a look at it and understand why.
What is weather definition in the project?
Project planning can be treated as a simplified predicted view of future events. As mentioned in article Traps of estimation (Strefa PMI 25) a big chunk of project planning is estimating. Estimate is a base of this future view of scope to be delivered.
Diagram 1 is suggesting how those estimates usually look like vs. reality as the scope of work may actually appear as complicated as the Earth atmosphere and different phenomena that takes place in it. Possibly the biggest uncertainty in the project is when bulk estimates need to be delivered to the Client. Then the project discovery team does the long term weather forecast. Nobody can deny, the team that time does not have sufficient information to precisely and accurately claim that it will be cloudy at 1 PM on Monday – the day 6 of sprint 3. A trap of that forecast is evident – estimates are very high level but can be treated as unbreakable for delivery by the Client. This is risky so shall we do forecasts and estimates and why?
Predict or not to predict?
Agile understanding of estimating is suggesting re-estimations and changes after each iteration (cone of uncertainty) but if you look in Scrum Guide you won’t see many references to estimation itself.
Generally there is no imposed method or technique you have to use – you can utilize tools which are working the best in your project situation (T-shirt sizes, planning poker, bucket system, dot voting, etc.). On top of that Scrum does not impose using estimates to check how much stories to fit in one sprint – it allows to rely on guess based empirical evidence. This is your team velocity that will decide about a number of stories burned out in the sprint – not estimate judgment. Surprisingly, there are such teams that are using no estimate approach, especially if you think about flexible and innovative startups that are usually not rigidly following all the project methodologies guidelines and adjust to their hectic environment. They are not deadline-driven but more looking at the quality, innovation, and idea of the product. Nevertheless, I bet there are a minority ofthe project teams that can have this freedom and comfort not to look on estimates at all. How then satisfy Clients that are deadline and budget-driven and require predictable timeliness or release dates with an estimate of the budget that they pay for? In other words why project weather forecasts are so important? You may consider a few points supporting the point of view that estimates are required to1:
- coordinate dependencies so that you do not go into circles with project work. Without umbrella you’ll get wet and unhappy because there may be nothing delivered E2E within the sprint;
- prioritize and align priorities – weather is important especially in agriculture – you need to know which work needs to be done first before the storm catch you in the middle of it. You need to organize work according to PO priorities but also according to technical dependencies and possibilities to fit into team capacity and skillset.
- validate which option is the best – what to wear providing predicted weather conditions? Which development approach is going to be the best in the environment that the project has and technical requirements of the Client or their IT landscape?
- predict what may happen – do the actual weather forecast. Will it be stormy or sunny in the sprint? Will you need additional time for investigations before development work is done? Does the team perceive that stories in the sprint are very complex and will not let them implement more than e.g. 20% of assumed stories prioritized by PO in a backlog?
- make sure the team has the same understanding of stories – forecast (estimate) helps to discuss differences in point of view and alignment of it within the development team.
- better coordinate the work – knowing weather forecast you can easily plan what will be the order of the activities and you can better coordinate your plans – same as development team in the project.
- make the progress visible – looking in spring on weather maps we can see that the weather will get better and better, which is analogous to the progress of work. Estimates are treated as a base to show how much work was done and where the project is according to high-level requirements. Moreover, estimates are one of four attributes of a product backlog, according to Scrum Guide (on top of value, description, and order), which shows the importance of weather forecast (estimates) for backlog realization during the project. All of the enumerated arguments lead to a simple conclusion – these are the factors that give transparency to the project, meaning fulfilling one of the most important pillars of Scrum framework that is critical for the empirical process. Which means weather forecasts (estimates) are really important for the project.
Moreover, estimates are one of four attributes of a product backlog, according to Scrum Guide (on top of value, description, and order), which shows the importance of weather forecast (estimates) for backlog realization during the project. All of the enumerated arguments lead to a simple conclusion – these are the factors that give transparency to the project, meaning fulfilling one of the most important pillars of Scrum framework that is critical for the empirical process. Which means weather forecasts (estimates) are really important for the project.
From long term to short term forecast
Starting with mentioned ballpark estimates in Scrum you possibly create the roadmap according to which estimates are iteratively updated within each of the sprints. The key here is to make sure the long term forecast is aligned with short term updates. It has one threat in it – Customer is still looking on the roadmap and you need to make sure an iterative approach to estimations is also communicated and you manage properly Client expectations.
As you know the weather forecast in different horizon has an attribute of predictability. Ballpark estimates are rather fortune telling, no matter if you use some analogous estimating or historical data as a base of it and embed expert judgment in it – it’s still something with a low level of certainty and predictability. Simultaneously, sprint estimates which the team is creating should be like a 3-day weather forecast showing the picture which is very close to the reality basing on the expertise of the development team.
In more project management words, weather forecasts (estimates) should be done on two levels – on the product backlog level, after story writing workshop, and on the level of sprint backlog during sprint planning. These are the recommendations of Scrum practitioners. Mike Cohn is suggesting that to be successful in both layers it’s the best to estimate product backlog in story points and go down into sprint backlog utilizing hours, nevertheless, I believe there may be a bit of polemics to that viewpoint within different Scrum teams. There are also such methods recommended as Crumbscale – using the scale and moving items on the scale that may be helpful to align both layers of estimations. Challenge and trouble in one are when the Client requires ballpark estimates on the product level in hours while your project is designed to work with story points. The alignment on both layers become complicated especially if the project scope is complex and not fully understood by development teams.
What if forecast does not work as it should?
Weather forecasting same as estimating is really difficult to bring value and make sure it fulfils its role. Once weather forecasts are unreliable nobody wants to use them and people are not eager to believe in that source anymore. Same with estimates that may influence the credibility of the teams and impact the trust of the Customer in the worst case. Good enough estimates/forecasts are extremely tricky and really very few are 100% right. Scrum practitioners are admitting failing with the estimates many times, nevertheless, it’s worth to look at first at the value that is delivered. Obviously, Scrum teams are not delivering story points but the value – that’s most important. Nevertheless, this forecast is still somewhere needed for proper work organization as well as for the Client understanding. Once they are not working as expected look at data with the intentions of improvement, check metrics and find solutions to be better and more accurate in following sprints.
Summing up, projects are having numerous elements that are analogous to weather forecasts and estimates are the closest to that analogy, which can definitely help to understand the importance of it.
Delivery Director in an IT company leading a business unit delivering different types of projects for the success of the Clients. Certified Project Manager who is considering Project Management as a science and an art. Project Manager working in complex cross functional and international environments realizing projects such as innovation and transformation, HR with focus on improvements, system implementations, transitions, integrations/ splits (M&A), go-to-market etc. After work – traveler who is looking for undiscovered and surprising places in Europe as well as all over the world. Amateur of macro photography, who likes listening to good music and interesting audiobooks. Usually, looking for perfection in the world around.