One of the most important principles of Agile is that everything, not only your product but especially your process, can change. And should change as well in case this improves the outcome for your team (in that way I totally agree with the failure of agile). During every project we do at Enrise, we find new tools and tricks and adopt them in our process to get the best outcome possible. In this post I want to share one of those simple but effective tools that helped us getting up to speed: the sprint plan overview.
How we used to do it
Let me give a short recap. At Enrise we use an agile approach for our projects, and mainly work with Scrum as a foundation for our own development process. We do sprints, we have product owners (hey, I really exist!), we do sprint planning sessions, etcetera. Cherishing the principle of the self organizing development team we let the team itself decide how to develop the product increment during a sprint. Pre-assigning backlog items to developers during sprint planning was not done. Whenever a developer would finish working on a backlog item, he would have a look at the to do column of the backlog and pick a new backlog item to start working on.
The problem we faced
Last year we started on a new large project with a partially new scrum team. The product’s domain was also a totally new planet to discover. Having quite a big sprint backlog in combination with the premature understanding of the product made the first sprints a bumpy ride. The velocity was low and communication about not completing the sprint goal was lacking or at least too late to manage the stakeholders’ expectations.
The cause of the problem
After a good retrospective with the team we discovered that there was no clear view on the bigger picture of a sprint. In case a developer would need more time for a backlog item he would not know the impact for the outcome of the sprint because:
- It was not clear how the backlog item was related to others and thus how much it would delay other backlog items;
- It was not clear how many other items that developer would need to complete (“maybe all other items can be picked up by other team members and there is no problem at all. Who knows…”)
The solution: create a better high level overview
During this retrospective we agreed that we would make a more detailed sprint planning at the start of the sprint. It looks like this:
The cool thing is that it is really just a very simple thing to do. During the sprint planning session, the development team decides who is probably going to pick up an item and when the team thinks it can be done. To be able to absorb some setbacks the team sets a freeze on the last day of the sprint. This means that on that day no items are planned. In the example used above, the team is not working on Fridays so on those days also nothing is planned.
Probably – making a plan at the start of the sprint does not mean that it can not change. In case it appears to be better to let another team member pick up an item or if there is any other reason to change the plan during the sprint, the team is free to change it
Done – done means that all workflow steps are completed including testing, and that the item passes our definition of done. This makes the team focus more on finishing items before starting on new items, which helps creating a sustainable pace
As the table visualizes the workload of the team and each individual team member, it is much easier for them to decide when the sprint is full and they get more confident that their commitment is realistic.
The sprint plan during the sprint
As the sprint evolves, the sprint plan gives the team a very clear view of the progress they are making. During the daily standup the team always has a look at the plan to see if they need to make adjustments. In case someone is behind in his planning because of some setbacks, the planning gives a clear view of the items that are in the ‘danger zone’. This helps the team figure out a way to reach the sprint goal. Like most other artefacts it is a helpful tool to get an important conversation going. The team can come up with solutions like changing the scope of the stories or changing the assignee (sometimes another team member is ahead of schedule and can help out a team member who is behind). In case the team can not find a way to adapt and still reach the sprint goal, they can collaborate with the product owner to adjust it and manage stakeholders’ expectations early on.
Keep looking for your own tools and tricks
The sprint plan table is a tool that helped our team out in this specific context. That does not mean that this tool is useful for every development team. It totally depends. My goal is to inspire others with this example to keep your process agile and always look out for the best tools and tricks for your own specific situation.
Let’s conclude with visualizing some scenario’s. Imagine that it is the Monday 9AM of this sprint:
Scenario 1 – Most items before Monday are completed. You are on track, keep up the good work!
Scenario 2 – Pay attention, we are getting too much behind. What can we do to catch up?
Scenario 3 – Ouch! This does not look good. Let’s adjust the sprint goal to get back to a realistic planning so that we manage expectations early on.