When I started my agile career 15 years back in Thoughtworks, it amazed me how often people would ask “Why?”. Any new process, or extra effort from the team, even new requirements, had to pass the “Why” test. We were conscious of doing things if and only if they added value. Other reasons weren’t good enough. Those were the days when agile wasn’t mainstream yet. Thoughtworks was one the vocal flag bearers of the movement. Bigger players still swore by the CMM levels and there weren’t as many large consulting firms that followed agile. Some did it under the radar, with little song and dance. Agile was still just a six-year-old upstart of the software development world.

In the 2020s, things are very different. Agile’s a 20 odd year old, “mature”, mainstream development and management philosophy. Maturity has its pros and cons. The advantage is that you don’t need to sell the approach too hard, either to stakeholders or colleagues. People have seen the benefits already. The disadvantage is that sometimes we don’t stop to ask the “Why” anymore. In a world of work that’s changed rapidly in the two years of the pandemic, I feel we need to ask the “Why” more than ever before. This is a new normal and as we switch between work patterns, such as forced-remote, remote-first, all-remote and hybrid, some practices will have to die. Others may have to change.

In today’s post, I want to explore two sprint ceremonies with a “Why” lens. I’ll also share a few ways you can buy back time for your team by taking lightweight, more async-friendly approaches to manage iterative development. If you’re an experienced practitioner, you can skip ahead to those ideas. Otherwise, keep calm and read on.

Why the ceremony?

If you look around the industry, you’ll notice that most people are following Scrum or a variation of it. I assume you’re familiar with much of the terminology, but let’s revisit some of it together. Along the way, let’s spend some time to agree on the rationale behind each practice. First, let’s ask why we work in sprints. 

The value of a fixed time-box

A sprint is a short, time boxed period when a scrum team works to complete a set amount of work. This is often a two-week period and sometimes, I’ve seen this to be shorter; i.e. a week long; or longer; i.e. a month long. The function of the fixed time-box is that the team makes a commitment to achieve a specific goal during this period. That goal corresponds to a fixed amount of work. In return for the commitment, the business leaves the team undisturbed during the sprint. 

Measurement is another advantage of the fixed time-box. Just like you need the fixed notion of what an hour means to determine speed; you need a fixed idea of how long a sprint is to know how much the team can deliver within that time-box. Story points are a popular measure of software size. Velocity, i.e. the number of story points a team delivers each sprint, is a common measure of team productivity.

Recapping, here’s the value we get from the idea of sprints.

1. Stakeholders have a clear idea of the team’s goal and the corresponding scope.

2. The team gets to work undisturbed during this time.

3. A fixed time-box gives us a common denominator to measure a team’s productivity.

The sprint planning meeting

This meeting starts the sprint. The idea is to agree on a goal with the team and to align on the development scope the goal corresponds to. I’ve observed several variations in this meeting, but I can tell you they’re rarely short. In fact, the Scrum guide recommends a time-box of “a maximum of eight hours for a one-month sprint”. Teams discuss several topics during this meeting, which contribute to that length. Apart from the sprint goal itself, here are some of the more common discussion topics.

• The scope itself. Teams will often discuss the details of each story and debate its place in the sprint. This can be a good time to discuss if the current DoR compliant stories deviate from the team’s initial assumptions of scope. If so, the team can trigger conversations to negotiate overall project scope with the business. 

• Estimates for stories. Especially when user stories have diverged from initial assumptions, the team will want to re-estimate them. This helps quantify scope change so the business can take it into account for the rest of the project plan.

• Capacity planning. The scope and estimation conversation eventually leads to discussion about capacity; i.e. how much can the team realistically deliver given the staff available during the sprint? Planned vacation, training days, company events, etc. impact the team’s capacity. These are considerations when a team plans the sprint.

To recap, the value we seek from sprint planning is as follows.

1. The team agrees on goals and the corresponding scope.

2. Project leaders generate data points to negotiate project scope with stakeholders.

3. All stakeholders can align with how the team will use its available capacity during the sprint.

And finally, the sprint review meeting

Sprint reviews are a way to showcase and celebrate a team’s achievements during a sprint. It’s often a presentation, combined with a demo. Business stakeholders and the team discuss the functionality a team’s delivered, along with metrics to gauge the team’s productivity. This is often an opportunity for feedback and also to inform steering decisions for the project. The Scrum guide recommends “a maximum of four hours for a one-month sprint.”, but I’ve rarely seen such long meetings. That doesn’t mean, of course, that these ceremonies can't be more effective. More on that soon.

Anyway, let’s recap the value of sprint reviews.

1. The team gets to celebrate what they’ve achieved.

2. Stakeholders get to see what the team’s delivered.

3. We surface information to measure the team’s productivity.

4. The business can use these meetings to inform steering decisions; some even for the next sprint.

You’ll notice that I’m not addressing retrospectives and standup meetings here. These are common scrum ceremonies, but I’ve addressed how to make them more async-friendly in previous articles. So check those out. If you consider a few minor tweaks, such as aligning on DoR, preparing before a meeting, limiting meetings to convergence only, you can reduce the length of sprint planning and sprint reviews considerably. I’d say you can bring them down to an hour each for a two-week sprint. Which is not bad at all. There are also a few ways you can optimise these meetings further, and in the next few sections, I want to explore those ideas with you.

Scope is the only true negotiable

How does a project get to be a year late? One day at a time. - Fred Brooks

If you’ve seen projects in action before, you’re surely familiar with the project management triangle. It defines the three variables you can use to manage a project. Change in one variable means a change in at least one more variable, otherwise quality suffers. For example, if you reduce the budget for a project, then you’ll need to either adjust the timeline or the scope you plan to deliver. If you keep the same timeline and the same scope as before the budget change, then quality will deteriorate. You get the point.

The argument that several agilists make is that scope is the only true negotiable. Here’s why.

1. Quality is sacrosanct. All agile engineering practices exist to achieve a high level of quality. Why tamper with that at all?

2. There’s never a fixed notion of scope. Scope always increases over the lifetime of a product as business context changes, as we get feedback from the market and as we come up with new ideas. This is a good thing, and this is exactly what agile accommodates when it says it values “responding to change, over following a plan”.

3. Adding people to a project may not make it go any faster. We’ve discussed this earlier when addressing how an increased team size increases communication complexity.

4. Releasing early gets value out faster and feedback quicker. So you’re better off releasing a smaller scope on time than waiting for the mythical notion of “delivering all the scope”.

5. The world gets better, one push at a time. If you’re continuously delivering, you can theoretically push features to production all the time. So even if you don’t deliver a specific piece of functionality in this sprint, you can deliver it in the next push to production. Continuous delivery makes it possible to release less functionality early, and the rest soon.

Principles #4 and #5 become even more powerful when the business prioritises relentlessly. That way, you get the most valuable functionality out of the door early and you can deliver the long tail of functionality over subsequent iterations. 

So why am I saying this? The point I want to make is that unless there’s an obvious need to agree exactly what a team will deliver in a specific sprint, you may not need a full-blown sprint planning meeting to agree scope. You may be better off getting to work on a well prioritised backlog and work your way from top to bottom.

Yes, another world is possible! Several teams will identify with the scenario I’m going to describe in the next few paragraphs. This is indeed the situation I found myself in as a product manager for a microservices platform. Our teams were all across Central and Eastern Europe, and we followed a fortnightly release schedule. Here are some practices we followed.

1. Focus on prioritisation and not sprint scope

Our business wanted the ability to respond as quickly as possible to our customers, so they often needed to move requirements up the queue if necessary. Fixing sprint scope was counterproductive to this. Of course, this could descend into chaos if there weren’t a few rules in place. So we put three guardrails in place.

1. We wouldn’t context switch developers and testers. So work-in-progress was always inviolate. All we could influence was the next item in the queue, be it a story or a bug fix.

2. The product manager’s role was to ensure that items in the “ready for development” lane were always in descending order of priority. 

3. Nothing could enter the “ready for development” until it met the DoR criteria for our team. 

2. Measure throughput and cycle time, instead of velocity

Our teams weren’t delivering on a contract we were going to overrun, so measuring story points wasn’t as important to us as getting stuff out of the door. Instead, we measured:

• throughput; i.e. number of items (tickets/ stories) delivered per sprint;

• and cycle time; i.e. the time it took for an item to go from an “in analysis” state to our definition of done (i.e. DoD).

I want to call out a couple of pitfalls and considerations here. 

1. Measuring throughput works well when you size items to have a similar size. Between the teams’ lead developers, testers and myself, we’d eyeball stories to see that they’re roughly the same size. This was a very rough estimation exercise and could we be 100% sure that all stories were exactly the same size? Hell, no! We weren’t aiming for accuracy, though. The trick with this approach is to know that if you eyeball for consistency, then over a sample, you’ll regress to the mean. 

2. Our teams still negotiated scope. Often, when analysing stories, we’d notice that the scope differed from our initial assumptions. Here, we’d slice the story down in other similar sized items and make sure our stakeholders were aware of the impact. 

3. We measured throughput only for functional stories. This was a good thing. If we saw our throughput going down, it often meant that we had too many defects slowing us down. That would mean that we needed to up the ante with test-driven development and improve our regression test suite. 

4. The cycle time metric forces you to optimise your system. Since the measurement applied to all functional items from “in analysis” to “done”, it meant we could have a huge inventory of stories in analysis. We had to communicate rigorously with our stakeholders to focus on the things that were important. At the other end of the process, testing could become a bottleneck, so not only did we improve our testing approach, we also got developers to double as testers when necessary.

3. The sprint exists only as a common denominator for measurement

When you examine the tweaks in this process, you see the sprint doesn’t need as much ceremony any more. 

• You’re pulling work from the top of a prioritised queue. The team gets as much done as possible and doesn’t pause because it’s the beginning or end of a sprint.

• Productivity measures still exist per sprint. They’re not as detailed as story points, but they’re simpler. 

4. Demos only when necessary

Let’s be honest. Teams don’t always have something big to showcase every sprint. In the absence of substantive demos, the sprint reviews become a formality and a reporting exercise. We took a pragmatic approach to sprint reviews instead. 

• Every two weeks, we’d create a report of what the team had achieved. This would include the stories on the project management system, our delivery and tech metrics and screenshots or video snippets where applicable. 

• Our stakeholders would look through the reports asynchronously on the project wiki (in this case, Confluence) and respond with feedback, kudos and emojis galore!

• When we had something big to showcase - for example, a new capability in the system; we’d organise a full-blown demo. Those were proper showbiz events. We’d plan for them, and get as much attendance as possible. They were as much an opportunity for the team to celebrate as one to show off what we’d accomplished! We did these demos once, every four to six weeks.

Your sprint ceremonies can be more async either by making the meetings themselves more effective or by taking a less strict scrum approach like the one I’ve outlined above. I understand that this approach may not work in all situations, especially those where the development team and the business are in constant battles over timelines and scope. In those circumstances, I argue you have bigger problems to solve than whether you’re more asynchronous or synchronous. Remote, distributed software development works best in an environment of trust and empathy. Focus on those fundamentals first and then address the practices on your team. 

The above approach also won’t work if there are contractual obligations that require you to estimate in story points or person-days. In such cases, my suggestion would be to continue with the sprint ceremonies. Follow meeting best practices to make these rituals efficient. Most often estimation makes sprint planning meetings long. Decouple estimation and sprint planning in this case. In a later post, we’ll discuss ways to conduct estimation asynchronously, outside the sprint planning ceremony.