Emperical Project Planning in the VUCA World

A few days ago a screenshot of the co-creator of Scrum, Jeff Sutherland's comment which says that estimating tasks slow us down, hence they stopped doing it 10 years ago, was published on LinkedIn and created quite a buzz with many even suggesting how futile it is to estimate and plan a project. If read carefully, we can find that Jeff mentioned the slowness experienced when tasks are estimated in hours. Teams create the tasks by breaking down the user stories. I would like to point out the fact that in Scrum Guide, not only Sprint planning is considered an essential event, but it also refers to forecasting based on the capacity of the team and its past performance, which is nothing but estimatin.

Scrum efficiently guides us to successfully manage the Volatile, Uncertain, Complex, and Ambiguous (VUCA) project without completely understanding the project’s requirements and environments from the beginning. Parts of the project requirements may no longer be needed after a few weeks or months of development. There also can be various changes in the requirements that may appear only after certain portions have been developed. Hence, Scrum emphasizes on the empirical process of transparency, inspection, and adaption to plan and develop a product.

In this article, I would like to describe how a VUCA project can be effectively planned in four stages.

1. High-level planning in a release planning meeting.
2. Detailed estimation in backlog refinement meeting.
3. Analysis of team capacity and planning delivery in the Sprint planning meeting.
4. More focused task-level planning in daily stand-ups.

• Release planning meeting: Release planning is an activity in which the Scrum team, including the product owner, along with the product manager and sometimes with senior management collaborates to create a high-level plan of incremental deliveries for the next quarter or the next six months or even next one year, i.e., a release plan containing a plan for several Sprints. Assuming the Scrum team decides on a two weeks Sprint, a normal quarterly release plan will include a high-level delivery plan for six Sprints. In a scaled Agile environment, where multiple teams work together, the release planning activity is called Program Increment (PI) planning.
  
  Why is release planning necessary? More often than not, the senior management needs to plan their finances to keep the show going until the next release. The sales team may need to know the possible next product launch date. They may also want to know what features that release will have so that they can go ahead with their advertising campaigns. Sometimes, product features need to be prioritized to decide what is urgent in the next three months (quarter) or what can wait until the next year. A release plan helps the organization in the above cases.
  
  What is discussed in a release planning meeting? Before calling for a release planning meeting, the product owner, with the help of the Scrum master, creates user stories from the requirements shared by the stakeholders and organizes them as per priority. The development team, product owner, and stakeholders (customers) come together for the release planning meeting to set their goals for the next release. The user stories are explained by the product owner. The development team then proceeds to estimate each user story, ideally in story points. During the release planning, several facts are unknown. Sometimes, estimates are conducted at a high level such that everyone can get a rough estimate of what can be expected in the next release.
• Backlog refinement meeting: Backlog refinement meetings are held to refine and prepare the backlog for the next upcoming Sprint. Since backlog preparation is held before the Sprint commences (ideally two backlog refinement meetings are scheduled a few days before the start of the Sprint), the Scrum team is aware of the priorities for the upcoming Sprint. Most of the unknowns that were unanswered by the product owner can get relevant answers and hence, the team has the advantage to increase the accuracy of their estimates.
  
  Backlog refinement meetings can be effectively used to refine the plan that was created in the release plan. The team can review the estimated and designated user stories to be included in the next upcoming Sprint. The advantage of using backlog refinement meetings for refining their estimations are a) The product owner can define the priorities for the next Sprint and the team can focus on those requirements; b) The team better understands to estimate the user stories; hence, the estimates would be more accurate c)Ambiguities are removed, unwanted items are omitted and relevant items are added in these meetings; therefore, their estimations will inevitably be more accurate after considering all the information provided d) Since the estimation part for the upcoming Sprint has already been done during the refinement, it saves a lot of time in Sprint planning which can be better utilized.
• Sprint planning meeting: The next level of planning is done in the Sprint Planning meeting. Since the estimates for all the high priority requirement has already been done, it is easier for the team to measure and count the number of user stories for the Sprint which will add up the story points to the team’s average velocity. Now that the team knows what needs to be done in the current Sprint, they can create a Sprint goal and commit to it accordingly. Further, the teams can divide each user story into smaller sub-tasks, so that multiple people can work on a particular user story. The team can also plan the deliveries of the user stories (days when they think they can deliver the user story along with their subtasks). Hence, Sprint planning can be used more effectively to perform sub-task level planning and delivery.
• Daily stand-up meeting: Generally, the daily stand-up meeting is to know what each team member did the previous day and what they are going to do that day. Daily stand-up meetings can be used effectively if developers are encouraged to give the status of the particular story and the sub-tasks they are handling, and if they foresee any difficulty in completing the story on the planned date. Thus, the daily stand-up meeting focuses on the sub-task level planning and monitoring of the user stories.

Simply put, the above four stages will help in the step-by-step project planning and will also help to monitor and deliver results consistently.