Scrum Dynamics 22 - Scrum Event Antipatterns

Carrying a stick of dynamite into a sprint planning meeting — an antipattern.

Carrying a stick of dynamite into a sprint planning meeting — an antipattern.

Some ideas turn out to be great ideas. Some ideas look like great ideas at the time but don’t turn out so well in hindsight. Those are antipatterns.

A pattern is a repeatable idea that solves a common problem, and should be adopted by others. An antipattern seems like an answer to a problem, but turns out badly and should be avoided by others.

There are hundreds of Scrum antipatterns you’ll encounter as you embrace Scrum in your Dynamics 365 projects. In this article, I wanted to highlight the top ten Scrum event antipatterns that I’ve witnessed in Dynamics 365 projects.

#1 Daily scrum is a status report

The purpose of the daily scrum is for the development team to update each other on their progress toward the sprint goal, to highlight any challenges they are having so that the scrum master, product owner and other developers can assist them after the daily scrum.

In Dynamics 365 projects, especially if you work for a Microsoft partner, your product owner is most likely a senior stakeholder from your customer's organisation. So it can be tempting to deliver your update to the product owner, or perhaps the scrum mater, and for the product owner or scrum master to ask follow up questions. Now it's become a status report, and that's not the purpose of the daily scrum.

Run the daily scrum like your product owner and scrum master aren't even there. If that's tricky, then don't even invite them for a sprint and learn how to provide a valuable update to each other. Just don't tell your scrum master that Neil Benson told you she's not invited to the daily scrum.

#2 Referring to story IDs in your daily scrum

I love user stories as a shorthand for the essence of a requirement.

But here are a couple of user stories title 'As a park ranger, I can log a work order for a park asset that needs repair, so that park visitors enjoy well-maintained equipment' or 'As a financial controller, I can process payroll within 2 hours every two weeks, so that all our employees can trust us to pay them on time every time.'

No developer, in their right mind, is going to say, “Yesterday I wrote the unit tests and completed the plugin development for 'As a park ranger, I can log a work order for a park asset that needs repair, so that park visitors enjoy well-maintained equipment'.” That's just too much of a mouthful. We all did that, we'd never finish the daily scrum in 15 minutes.

Instead, we often resort to an antipattern: referring to story IDs, card IDs, ticket numbers or issue numbers. We say 'Story 258' instead of 'As a park ranger, I can log a work order for a park asset that needs repair, so that park visitors enjoy well-maintained equipment'.

Worse still: pointing the board and saying, “Yesterday, I worked on this card and today I’m going to be working on that card.” 

There has to be a better pattern to the story ID antipattern. Mine is to write a short title for each user story. Just two or three words so that everyone on the team knows which story I'm referring to. How about 'Log work orders' or '2-hour payroll processing'?

 #3 Problem solving in the daily scrum

One of the things we should be doing in the daily scrum is highlighting to our team mates any backlog items we're struggling with or might not complete this sprint. It's the scrum master's role to uncover these blocked items and help them team unblock them.

Other team members can help too. Perhaps another developer has faced a similar technical challenge before, knows someone else in the organisation who can help, has some spare capacity or would like to know more about the problem.

It's great that developers want to help each other. The daily scrum is a great place to offer help. But it's not a great place to provide the help. Save it for later. Let your team mate and the scrum master know you've got an idea, and then hang back after the daily scrum is over to discuss it further.

The daily scrum is time-boxed to 15 minutes but it doesn't have to last 15 minutes. If everyone's caught up after 7 or 8 minutes then we close the daily scrum and get back to work. We don't fill up everyone’s remaining time with an impromptu problem-solving session.

The daily scrum isn't a workshop. It's not for solving problems or unblocking challenges. Save your effort for later so that the rest of your team can get back to work. Respect the time of your other team mates.

#4 Sprint planning based on recent velocity

The two Scrum squads that I'm working with on the Jupiter programme recently each completed an average of 21 story points over the last three sprints. As we began to plan sprint 8 and sprint 9, which fell during the Christmas holiday period we would have been crazy to forecast 21 points for sprint 8, which finished on 31 December or 21 points for sprint 9, which finished two weeks later on 14 January.

During sprint 8, the 15 team members had two days' public holidays and between them had planned 43 days' leave. That means out of the usual 150 working days in a sprint, we had zero capacity during 73 of those days. That's half a sprint on holiday.

Sprint 9, was similar. There's a public holiday on 1 January, and a lot of the team had taken a week or two of planned leave to enjoy the Australian school summer holidays with their families. So we lost 19 days' effort during sprint 9.

I enjoyed my leave with my family during this period, and my team certainly deserved theirs too, but we would have been crazy to run sprint planning for sprints 8 and 9 if we hadn't taken our capacity into account.

The antipattern here is to forecast your velocity based on your recent history without taking into account your known capacity for the upcoming sprint.

There are worse antipatterns (such as sticking to the predicted velocity you imagined the team might have before the project started), but a better pattern is to forecast future velocity by combining recent velocity with your team's known capacity.

 #5 Refining items into tasks during sprint planning

OK, this one is a little controversial perhaps. I know some Scrum teams seem to benefit from taking the time to refine their product backlog items into tasks, sometimes even going to the extra effort to estimate those tasks in ideal hours and checking that the total number of ideal hours is less than the total number of available hours in the sprint.

My experience with this extra effort is that it's definitely an antipattern. On the face of it, it seems like this practice might be helpful, and if you're using this practice in your Scrum team today it might appear to be helping your team. It might.

But I'd encourage you to discuss dropping task-level estimates in your next retrospective, and to try running a sprint without tasks. Do you go slower? Do you have difficulty tracking your progress? Do you have communication challenges?

My teams didn't actually experience these side effects when we dropped tasks and started tracking the progress of our stories across the Scrum board as our only measure of progress. If we did start to feel any side effect, we quickly found an easy way to compensate for it during our next daily scrum.

One side effect I did find: it cut sprint planning time in half. The second half of the sprint planning event was done in 30 minutes instead of two hours. We saved ourselves a lot of painstaking task related work, and we actually improved the visibility of our progress because there was less clutter on our Scrum board.

#6 Sprint goal that summarises the sprint backlog

The sprint goal should a unifying objective that provides the development team with an ambitious theme for the sprint. It helps us prioritise and focus our actions during the sprint so that we know how to deliver valuable software for our product owner without asking a thousand questions a day.

The sprint goal is often drafted by the product owner. It should be finalised by the scrum team during sprint planning once the development team has forecast which items it will complete in the sprint.

 Sprint goals could include, 'Prototype using the Data Export Service to populate the data warehouse' or 'Complete the integration with Adobe Campaign for offer management'.

Ideally, there is one shared goal. It supports prioritisation, creates focus and facilitates feedback, helps obtain relevant feedback from the product owner and stakeholders, and supports the team's stakeholder communications too.

In my Dynamics 365 projects, sprint goals for early sprints are often about discovering new things, to reduce technical risks and test viability of different ideas. As the project progresses and our architecture matures, the sprint goals turn towards a more feature-driven focus.

The antipattern sprint goals look like they should provide the clarity and focus of a good sprint goal but they don't. The common reasons for this are:

  • The goal was written by the product owner as a non-negotiable stretch target

  • The goal is just a restatement of an epic being delivered in the sprint

 But the worst, and most common sprint goal I've seen is when

The sprint goal says something like 'Complete the stories for sales quotes, case management and lead assignment'. This sprint goal anti-pattern is just a summary of a collection of unrelated user stories. It summarises what we're building but doesn't tell us why.

 By the way, it's OK to have an ambitious sprint goal and not achieve it. Obviously we'd rather achieve the sprint goal than not, but, for example, I've had several sprints where the goal was to demonstrate how users can handle an inbound call using Unified Service Desk (USD). But in each sprint we ran into infrastructure issues that blocked our USD demos. It was frustrating, but we kept learning lots about how to configure our infrastructure to support USD, and we kept developing more features in our development instance even though the demonstration instance was blocked.

 #7 Special sprints

The purpose of a sprint is to produce an increment of working software that the product owner could choose to release into production if she wanted to.

She might choose not to release it into production for lots of valid reasons. Some teams plan to release to production every sprint, but most teams release less frequently, maybe every two or three months. But the important thing is that the scrum team has completed all the work required to release the increment into production, if that's what the product owner chooses to do.

 There shouldn't be any work left undone. The development should be done. The documentation should be done. The system integration testing should be done. The acceptance testing should be done. The release rehearsal should be done. The only thing you've got left in the product backlog is a small chore to schedule the actual release in your automated build and deployment tool.

Some Dynamics teams, especially those new to Scrum or working in an organisation where most other teams are not very agile at all, find themselves with special sprints dedicated to making their increment release ready. They're known as hardening sprints, testing sprints or release sprints. These special sprints create no valuable software at all.

On my current project we running Scrum within an IT organisation whose policy dictates four weeks of system integration testing, four weeks of user acceptance testing and two weeks of disaster recovery and performance testing prior to the initial release of any major new system. Like every policy ever written, this release policy was probably written in response to a big screw up sometime in the past. Now everyone has to follow the policy to try and avoid the same screw up. Instead of continuously testing and releasing software incrementally, as we'd like to do in a Dynamics 365 project when we using Scrum, we have to hand over our test instance and let other teams take ten weeks to satisfy themselves it's ready and then we can release it.

This ten week delay for testing is definitely an antipattern.

But I'm grateful the CIO chose Dynamics 365 and asked me to deliver it and let me use Scrum. Instead of fighting for an exception to the policy, I'm planning to follow it and demonstrate it wasn't necessary. Hopefully a successful agile implementation of Dynamics 365 with Scrum will make it easier for future agile projects to influence the policy.

#8 Changing the sprint backlog mid-sprint

When I started using Scrum ten years ago, the sprint backlog was a commitment rather than a forecast. You won't find the word commitment in the Scrum Guide since its revision in 2011.

Sidetrack: it's a good idea to reread the Scrum Guide every year, especially in years when a revision has been published. The changes are often subtle, but based on feedback from thousands of Scrum teams, so worth paying attention to.

So when my scrum team formed the sprint backlog during sprint planning, we weren't just hoping to deliver the items in it. We were saying to the product owner, "We're committing to delivering these items in this sprint. Nothing more, nothing less."

Of course, what happened is that something urgent, super-critical bug or requirement would pop up and we'd whine when the product owner asked us to change our sprint backlog. Or some other team would be unable to remove a blocking impediment before the end of our sprint. Passive aggressive developers would tut and wear a snarky Dilbert t-shirt the next day, the aggressive aggressive developers would drink a litre of Mountain Dew then spending the rest of the afternoon shouting and ranting about commitments. The poor scrum master would be left trying to remove an to-do item from the backlog the same size as the new one so we didn't completely screw our velocity.

Experienced scrum teams, on the other hand, expect some urgent, super-critical bug or requirement to pop-up mid-sprint because that's software development. There will occasionally be unexpected, blocking impediments that our team can't remove. Our sprint backlog needs to be a little flexible. We need to be able to change the sprint backlog mid-sprint.

Hold on. Didn't I say that changing the sprint backlog mid-sprint is an anti-pattern. So which is it? A pattern or an antipattern?

It's an antipattern when a maverick developer picks up an item in the product backlog and slips it into the sprint backlog without consulting the team.

It's an antipattern when the product owner coerces the team to add new items to the sprint backlog without removing others.

It's an antipattern to change so many of the items in a sprint that the sprint goal is no longer relevant.

So adjusting the sprint backlog mid-sprint, if done carefully, consultatively, collaboratively isn't an anti-pattern. We're updating our forecast, not breaking a commitment.

 #9 Accepting items as done at sprint review

I used to think that the development team presented each completed item during the sprint review, usually by demonstrating the feature in Dynamics 365. And product owner accepted each item, only very occasionally rejecting an item, and sometimes creating new stories to enhance or modify one of the new features she saw in the demo.

Maybe that was just me. Maybe it was just my early Scrum projects that ran like this with a hands-off product owner that was mostly available at the start and end of each sprint, but not much during the sprint itself.

But that changed for me around 2012 when we had a much more hands-on, available and invested product owner who was happy to see features demonstrated before they had been declared done. If there was enough time, she could see her feedback incorporated before the sprint review.

The Scrum Guide says that during the sprint review the product owner's role is to explain what items have been done and not done.

That explanation about what's done and not done isn't for the benefit of the the developers. It's for the rest of the stakeholders. If it's a surprise to the developers that they only find out at the very end of the sprint what's considered done and not done, what has been accepted and not accepted, then that's an antipattern.

#10 No retros

A friend of mine, Ian Dawkins, ran a very successful CRM consultancy called Concentrix in the midlands of England. As well as running Concentrix, Ian was also in the process of becoming an official golf referee with the Royal & Ancient Gold Club of St. Andrews.

Ian used to scold me for playing golf with 'gimmes'. A gimme is when another player in your group putts near the hole, usually within 30 or 40 centimetres and you give him or her a gimme, meaning that they can pick their ball up off the green as if they had putted it into the hole for a single extra stroke. Asking them to actually putt out takes extra time, and might cause them embarrassment if they miss such a close putt.

Gimmes don't appear in the R&A rules of golf. They are an adaptation that social golfers have made to the game of golf, and in Ian's opinion, if you played with gimmes then you were playing a game that resembled golf but you weren't playing golf. Gimmes, in Ian's mind, are a golfing anti-pattern.

By now most of us know that Scrum’s three roles, five events and three artefacts, as well as the three pillars and five values are immutable. You can't use half of Scrum, or most of Scrum, or nearly all of Scrum, and still declare you're using Scrum.  

In my experience, it's the sprint retrospective that is most likely to be dropped by a team using Scrum. Except now, of course, they're not using Scrum. They're applying a framework that looks like the Scrum framework but it's missing an essential, immutable component: the sprint retrospective.

There are usually three reasons given for skipping the sprint retrospective:

  1. We find the sprint retrospective valuable but we're under too much pressure to meet a release deadline and we simply haven't got the time to gaze at our navels for a couple of hours.

  2. We don't find the sprint retrospective valuable any more. We've been working together for months or years and we don't need to change our process. We've got Scrum down pat. We don't need to spend a couple of ours gazing at our navels.

  3. We've never found the sprint retrospective valuable. It's just an opportunity for whining developers to complain about the stakeholders, and that one time that the product owner was invited a fight almost broke out. 

Look, I don't care if you play golf with gimmes. (Personally, I think it speeds up the game a little and – sorry Ian – but golf is already so slow.)

But, whatever excuses you might hear for no retros, fix them. There are lots of resources to help you identify what's going wrong in your retrospectives if you don't find them useful. Every experienced scrum master or agile coach should be able to facilitate a sprint retrospective and bring a fresh perspective to your recent sprint and help you identify a couple of improvement actions to try in the next sprint. Even for the next 100 sprints.