As we promised last time, here we go with another Planning mode. This time it is going to be about ad hoc Planning.
Mode #3: Ad hoc planning
This mode is when the team does not plan for the upcoming Sprint during the Planning session, but instead, takes items into development from the top of the prioritized Backlog.
The Development team does not commit to a specific number of items they would have to deliver by the end of the Sprint. They just pull User Stories from the top of the ordered Backlog. A good habit is to take new a User Story into the Sprint after the previous one has successfully finished. At that time, it is possible to predict the amount of work the Developers are able to deliver based on the team’s velocity.
This mode allows the team to react quickly to changes in customer requirements that affect the Product Backlog. But as a result, the Product Owner has to keep an eye on the Backlog more than ever. It has to be ready every single day, prioritized according to the needs of the business, because at any time Developers could have capacity to start working on another User Story. That also means that the Product Owner has to be in regular contact with the stakeholders to ensure correct prioritization. If stakeholder priorities change, they have to be reflected in the Backlog immediately.
So, what does this mode of Planning mean for Developers? Once they finish their work on a User Story, they have to visit the Product Backlog and take the item at the top. However, they can always negotiate switching the order of items in the Product Backlog with the Product Owner if they feel that from a development point of view, there needs to be a change in order. For example, if the current order of User Stories would make development difficult or blocked, User Stories can be moved around to remove those barriers.
So, how would the Burndown Chart look?
Since the team does not plan a certain amount of work during Planning, but instead, Developers pull new User Stories into the Sprint as they finish the previous ones, the Burndown Chart will look kind of like this:
Why? Each User Story’s size has to be estimated and broken into Tasks, which are then assigned hours from which the Burndown Chart is calculated. The size of each User Story is different, so that is why you see different “ups and downs” in the Burndown.
And what about the Sprint Goal in this mode of Planning?
The Sprint Goal captures what we are trying to achieve in the Sprint. In this case, it should also shed light on the reason why this Planning Mode was selected.
Now, do you still want more? Good. We have one last Mode of Planning for you.