Agile Scrum, Or Not-So-Agile Scrum?

This content is syndicated from by Kelly Waters. To view the original post in full, click here.

Agile Scrum, or Not So Agile Scrum?

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!

Photo by incase

Leave a Reply

Your email address will not be published. Required fields are marked *

nineteen − 5 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch