Agile Scrum, Or Not-So-Agile Scrum?

Get insights in your inbox

Scrum is the form of agile software development that has helped me the most.

It has helped me to transform the performance of the web development groups that I’ve led at both my current company and at my last one.

But, sometimes, I do wonder if Scrum is really agile enough?

There are quite a few regular meetings in Scrum. For short Sprints, this can be quite a big overhead. For me, that’s where I can see why the Lean methodology appeals, especially to developers.

But there is also value in these meetings. So I thought I’d take a look at each Scrum meeting in turn, and assess whether or not their value really outweighs the effort?

First, there is Sprint Planning.

Sprint Planning happens before every Sprint. In our case, that’s generally every two or three weeks. In Scrum, this meeting is split into two parts…

The first part is to discuss the requirements for all the User Stories intended for the Sprint as a team and give everyone on the team the chance to understand what is required. Questions are asked, and hopefully answered, that give people useful insight into how each User Story will be designed. Ambiguity is reduced and the team, hopefully, gains a common understanding of the User Stories and the requirements for the next Sprint. The collective experience of the team means that everyone gets the chance to input and the quality and appropriateness of the solution is potentially improved as a result. For a 2 week Sprint, this part of Sprint Planning generally takes about 2 hours, maybe less if the requirements for the relevant User Stories are well understood or well prepared beforehand.

Without this meeting, this discussion can still happen ad-hoc as and when someone picks up a User Story to develop. However, the chances are that the discussion will then occur with just the Product Owner, or perhaps one or two user representatives. It will be less onerous than having the whole team involved, that’s for sure, but it won’t benefit from the wisdom of crowds that you get from the group approach to Sprint Planning. The other thing about this ad-hoc approach is that it’s more onerous for the Product Owner. They would need to be available most of every day and at the beck and call of the development team. If your Product Owner is not full-time and sitting with the development team, Sprint Planning is a useful way to ensure sufficient access to their time, and it’s a useful way to pre-plan this regular event in everyone’s diaries.

Weighing all of this up, I personally believe Sprint Planning is costly (in terms of time) but really worthwhile.

The second part of Sprint Planning can happen immediately after the first part, although some teams leave a day or so’s gap between the two meetings, in order to clarify any outstanding questions before going to the next stage. The purpose of this second part of Sprint Planning is to plan the Sprint in detail.

The idea is that the team works together to break down all the User Stories into tasks, and estimate each task in hours. The team then plans their capacity for the next Sprint and decides collectively how much to commit to in the Sprint.

Personally I think it is useful to think about the tasks for larger User Stories, but unnecessary to do this for the smaller or simpler ones. Although Scrum suggests estimating all of the tasks in hours and going through this detailed planning process, personally I think this has some negative effects…

Obviously it can potentially take quite a long time, and with the whole team involved, that makes it an expensive meeting. But I also think – ironically – it can really hinder a team’s ability to deliver on time. There are two reasons for this. Firstly, the team only estimates the tasks it can identify. They don’t estimate the tasks they haven’t identified. Inevitably there are some. Secondly, we all know by now that most developers are hopeless at estimating. Inevitably it their estimates will be wrong.

If you’re on a large project, you may have already estimated all the User Stories on the Product Backlog in Points, in order to get an idea of how big the overall project is. If so, I personally think it’s much more accurate for the team to commit to how many points they think they can deliver in the Sprint, and stick with that instead of estimating tasks in hours and trying to plan them in detail. In my experience, once a team’s Velocity (the number of points delivered in a Sprint) has stabilised, this is a much more accurate way to gauge what a team can deliver in a Sprint, and it takes less time to do. For more information on this, see my post The Secret To Delivering On Time.

If the User Stories being discussed in the first part of Sprint Planning have not yet been estimated in points, I would suggest the team voting on the size of each User Story once its requirements have been discussed. Planning Poker is a great technique for doing this.

So, in summary, my personal view of Sprint Planning is this: It is worthwhile to discuss the requirements for the intended User Stories for the next Sprint as a team. It is worthwhile to estimate the User Stories in points, either when they go onto the backlog, or using Planning Poker to estimate them as a team in Sprint Planning. It is worthwhile for the team to make a collective decision about the amount of points they are able to commit to for the next Sprint, based on their experience of their past Velocity. Whereas breaking every single story into tasks, aiming to identify every task, estimating each task in hours, working out the precise capacity of the team for the next Sprint, and committing based on that, is not necessarily worthwhile. It takes a long time and can lead to less predictability about what can be delivered, meaning the team doesn’t deliver on its commitments and people are disappointed.

During the Sprint, the only regular meeting in Scrum is the Daily Scrum itself.

This is where the whole team meets every day to answer three basic questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Is there anything blocking your progress?

This meeting should take between 5 and 15 minutes. No longer.

There is no doubt in my mind that the Daily Scrum is extremely worthwhile.

It keeps the whole team joined up and provides the Product Owner with clear visibility of progress and any issues affecting the team. This is one of the key ways that Scrum helps to ensure that development teams can keep stakeholder’s expectations in line with their emerging reality. This is critically important. The definition of a successful project, at least in my mind, is one that meets or exceeds expectations. Therefore I would never personally suggest that a team does not have their Daily Scrum. It’s a way to manage expectations on a very granular level, ensuring expectations and reality don’t diverge along the way.

At the end of the Sprint, there are two more meetings: the Sprint Review and Sprint Retrospective. These are useful meetings, but because they’re at the end of the Sprint, they coincide with the Sprint Planning meeting which is at the start of the next Sprint. Sometimes this can make it seem like meeting overload for about 1 day of the Sprint, which to be honest can be a bit wearing.

The purpose of the Sprint Review meeting is to invite all interested people to come and see what the team has achieved in the last Sprint. If this is kept brief and informal, I think it’s really nice for the team to show what they’ve done. It’s also really nice for people interested in the project that can’t be involved all the time to see what’s going on and have the chance to provide regular feedback. This is another important mechanism to manage expectations in small, bite-sized pieces, which I’ve already mentioned I think is critically important to the success of any project. It’s also a useful motivator for the team to achieve good results in each Sprint, as there will be a Review meeting afterwards so it tends to keep the team more focused on delivery.

And last but not least, the Sprint Retrospective. The purpose of the Retrospective is to build continuous improvement into the regular Sprint cycles. Again, there are three key questions to be discussed by the team in the Sprint Retrospective after each and every Sprint:

  1. What went well?
  2. What didn’t?
  3. What will the team do differently in the next Sprint?

Doing these Retrospectives so regularly throughout a project means that the learnings actually help to improve the team’s Velocity throughout the project (and beyond). If it’s kept simple, the things the team want to do differently in the next Sprint should be actionable and should actually make a difference to the efficiency and wellbeing of the team and the project. There’s no question this is a meeting you can’t afford to give up. There’s just too much value in it.

However, because it coincides with so many other meetings at the start and end of each Sprint, it’s important to keep it brief. For a 2 week Sprint, half an hour should be plenty of time to quickly brainstorm these three questions and action any changes in the next Sprint.

So, in summary – whilst on the face of it all these meetings don’t seem very agile, I do believe the Scrum meetings do help the team to be agile throughout each Sprint. They help the team to gain a common understanding of what’s required, improving the quality of the solution. They help the team to have a common understanding of progress and issues, improving the level of teamwork and visibility for the wider team. They help the team to see what’s been achieved, improving the level of satisfaction and helping to manage expectations. And they help the team to learn from past issues and improve on them in the very near future.

My conclusion? Talking takes time. But it also adds value.


For more information on Scrum, see my series: How to implement Scrum in 10 easy steps!