Share
A few days ago Scrum's co-creator, Jeff Sutherland's comment on the futility of estimating created quite some buzz within the LinkedIn tech community. According to Sutherland, estimating tasks slow us down and so it is an outdated practice he stopped recommending ten years ago. If read carefully, we can see that Sutherland highlights the lag experienced when tasks are estimated in hours.
I would like argue that in Scrum Guide, not only is Sprint planning 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 estimating.
Scrum efficiently guides us to successfully manage the Volatile, Uncertain, Complex, and Ambiguous (VUCA) projects. This is particularly effective for project with changing or incomplete project’s requirements and environments. For many projects, parts of the project requirements may no longer be needed after a few weeks or months of development. Even after the project is well underway, there may be changes in the requirements along the line. Hence, Scrum emphasizes 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:
- High-level planning in a release planning meeting.
- Detailed estimation in backlog refinement meeting.
- Analysis of team capacity and planning delivery in the Sprint planning meeting.
- 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 management) collaborate to create a high-level plan of incremental deliveries for the next quarter, next six months, or even next one year - a release plan containing a plan for several Sprints. Assuming the Scrum team decides on a two-week Sprint, a standard 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 ball rolling until the next release. The sales and marketing teams may also need to know the next possible product launch date and be informed on what features that release includes so they can sell it effectively. Therefore, a decisive voice must prioritize what product features are urgent in the next three months (quarter) and what can wait until the following year.
- 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 by 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 product owner often explains the user stories, after which the development team estimates each user story, ideally in story points which are further discussed during the meeting. For example, sometimes estimates are rough and high-level so everyone can get a quick and dirty idea of the next release and what changes it will include.
Backlog refinement meeting: Backlog refinement meetings help the team prepare the backlog for the next Sprint. Since backlog preparation occurs before the Sprint commences (ideally, two backlog refinement meetings a few days before the start of the Sprint), the Scrum team is aware of the priorities for the upcoming Sprint. The team can get clarity as unanswered questions are finally addressed by the product owner allowing the team to increase the accuracy of their estimates. Backlog refinement meetings can be effectively used to refine the plan created in the release plan. The team can review the estimated and designated user stories in the upcoming Sprint. The advantages of using backlog refinement meetings include:
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 how to estimate the user stories; hence, the estimates would be more accurate
c)Ambiguities and unwanted items are removed, 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 is done during the refinement, saving a lot of time in Sprint planning
Sprint planning meeting: Sprint Planning meeting is the next stage. Since the estimates for all the high-priority requirements are done, it is easier for the team to measure and count the number of user stories for the Sprint, which will add up the report points to the team’s average velocity. Now that the team knows the next steps, 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 simultaenously. The unit 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 for sub-task level planning and delivery.
Daily stand-up meeting: Generally, the daily stand-up meeting is to learn what each team member did the previous day and what they will do that day. Daily stand-up meetings are effective if developers are encouraged to give the status of the particular story, the sub-tasks they are handling, and if they foresee any difficulty 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.