Self-selecting teams with just two teams

Self-selecting teams on a small scale

You don’t need a lot of people for self-selecting teams to be useful.

Self-selecting teams is a practice where people get to choose for themselves which team they want to be in. Typically, it is associated with large scale agile implementations and obviously it does make sense to tackle the complicated task of organising 50 or 100 people into teams the same way we as so often solve complicated tasks in agile: self-organisation. But how about using self-selection on a much smaller scale?

In this post, I will describe a recent experience I had with self selection in our two Scrum teams. Spoiler alert: it worked great!

First, a bit of background.

I work in a team that is one amongst many others in a large organisation. We are 16 people in total, including developers, testers, UX, product owner and the scrum master (hey, that’s me! :). In the past, we’ve tried running the team as one big Scrum team but found that it didn’t work very well, so we have split the team in two smaller teams. We call these sub-teams “crews”.

A few weeks ago, we had just finished the project we had been working on for the last several months. A few people had come and gone in the process, so our two crews had ended up being quite un-balanced in size. With new work about to start, it was time to form new crews.

The last time we did this, the tech lead decided who would be in each crew, which worked perfectly fine. This time round, though, the two crews would be working on two completely separate work streams. That meant it would potentially matter a bit more for people which crew they were in.

Starting to think about the new crews, a rather obvious idea started to form: why don’t we let people decide for themselves? Let’s try self-selecting teams!

The self-selection workshop

The day arrived and here’s the agenda we followed:

  1. Describe what each crew will be working on
  2. Agree what skills are needed for each crew
  3. Select the crews
  4. Choose team names

1. Describe what each crew will be working on

The first point was to describe what work each crew would be working on. For calendar-technical reasons, we had actually covered this in a separate meeting a couple of weeks beforehand, so we were able to just do a quick 5 minute summary, running through a few bullet points for each as a reminder. I’d probably do the same next time, as the separate session gave people time to think a bit about the upcoming work and it also helped avoiding the actual self-selection workshop getting too long.

2. Agree what skills are needed for each crew

As the facilitator, I then described what we were aiming for: two crews, each including all the skills necessary to deliver their work end-to-end and with roughly the same capacity for both crews.

Based on this, we discussed if we needed to be a bit more specific about the skills required for each crew. The list we ended up with was general and straightforward:

  • Development (including a senior developer)
  • Testing (including test automation)
  • UX design

3. Select the crews

Next was the main event.

I reminded people that they were free to choose whichever crew they wanted and it was entirely up to them how they made their choice. Some things they might want to think about were what they wanted to work on, what they could contribute to the crew’s goal and what would make sense in terms of creating well-balanced crews.

In preparation, I had written each team member’s name on a post it and put on the wall. When the selection started, each person took the post it with their name and once the new crews started to stabilise, they put their name on the wall representing their crew.

Reading about how others have done this, common practice seems to be to run a number of 20 minute iterations where people move into possible teams, evaluating the result after each attempt and repeating until all criteria were fulfilled. I suspected that would be over-kill for a group this small, so I set a ten-minute timer, explaining that if we hadn’t finished by then, we would discuss together which criteria we hadn’t met yet and what we could do about it.

It turned out that there was no need for the timer as less than three minutes later, we had our two ready-formed teams.

4. Choose crew names

The last point of the agenda was for the crews to choose their new names, which they set out to do with much enthusiasm. It was really great to see everyone getting together to solve their first task in their new crews!


We created our two new teams in just under an hour and even had quite fun doing so. The resulting teams didn’t feel miles apart from the choices I imagine the tech lead would have made but had the important benefit that everyone was in a team they had chosen themselves. I don’t know if anyone ‘sacrificed’ themselves and went to a different team than they would have preferred, just to balance things out, but if they did, they did it of their choice, which must be a much better thing than being told “you will be working on this work and these are the people you will be working with”.

Self-selecting teams is definitely a method I will look at again the next time it’s time to form new teams.

I first published this post 11 July on my blog on Medium.

5 things I’ve learned about Scrum the hard way

Woked well, didn't work and ideas

I got my Scrum Master certification in 2007 and have been using Scrum in many of the teams I’ve been working in since then. It’s fair to say it’s been an educational journey and in this article I’d like to mention a few things I’ve found out along the way.

Scrum works best for small teams

1. Scrum really does work best for small teams

I’ve tried using Scrum with teams of many different sizes. Sometimes they’ve even been above the 9 person dictated maximum. In those cases, it often didn’t work very well at all.

It gets very difficult for a team to self-organise to deliver their work in the most effective way when the team gets too big. It is also hard to feel that everyone is in it together and collectively responsible for delivering the work in a team that big. Sure, 16 people can divide the stories amongst themselves and get the work done but by doing so, they miss out on many of the advantages of Scrum and Scrum risks feeling like just an overhead. For instance, it’s fair to say that most people would like to use their time better than a sprint planning meeting or daily scrum where only 10% is relevant to them.

I’d say the ideal team size is probably 4–5. That’s a big enough team to get the benefits of being a team, such as having people with different skills and ideas working together. Also, a team this size should be able to get through a reasonable amount of work each sprint, without grinding to a halt when, for example, someone is on holiday or ill.

The sprint retrospective is the most important meeting in Scrum

2. The sprint retrospective really is the most important meeting in Scrum

According to the The State of Scrum survey from 2015, almost one 1 out of 5 teams don’t bother having a retrospective at the end of each sprint and I can actually see why. A badly run retrospective can be a waste of time, boring and even quite disruptive!

To be honest, some of my retrospectives have been pretty crap. The same points kept coming up sprint after sprint and the whole thing started feeling rather pointless. With one team, I even tried what happens if you scrap retrospectives altogether. Admittedly, we didn’t actively set out to do it but we were up against a tight deadline a few sprints away and felt that, on a whole, our process was working fairly well, so we said “Let’s not do a retrospective this sprint and use the extra hour to complete more work in the sprint!”.

Needless to say, at the end of the next sprint, the deadline was even closer so we skipped the retrospective again. The deadline came and went, so now we really had to finish things in the next sprint. Definitely no time for a retrospective!

It should have been obvious that we had a problem but rather than stopping up for an hour and thinking about how we could make things right, we just kept rushing ahead, reasoning that we could talk about the process once we’ve delivered what we needed.

Only that we didn’t deliver. Finally, we had no choice but to to stop and go back to basics. By then, we had wasted a lot of time and effort.

Since then, I have learned a lot from practice, blogs and books. I’ve learned that through identifying the root causes of the issues we are seeing, so that we don’t just tackle the symptoms, and making sure that the actions we agree on are achievable by people in the team and that we actually do complete them, retrospectives become as an incredibly powerful tool for the team to be as effective as possible.

Henrik Kniberg is spot on in his book Scrum and XP from the Trenches:

“[Sprint Planning is the] most important event in Scrum? No! Retrospectives are waaay more important! Because well-functioning retrospectives will help fix other things that are broken.”

That is very true.

A sprint goal is not a list of Jira tickets

3. A sprint goal is not a list of Jira tickets

For a long time, I told my teams that the sprint goal is the list of user stories we are intending to complete in the sprint (often represented by a bunch of tickets tracked in Jira). What I failed to realise was that through doing this, we were giving up the flexibility we needed to be able to achieve a useful goal.

If our goal is to complete XYZ-123, XYZ-124, XYZ-125, XYZ-126 and XYZ-127, we would unavoidably miss this goal if we for some reason couldn’t complete XYZ-125.

Instead, let’s say that our sprint goal was to complete a first version of the shopping basket, in order to allow us to do a round of user testing. In this case, if we start running out of time in the sprint, we can discuss with the product owner what is genuinely needed or not. If they agree that it would be acceptable not having the functionality to adjust item quantities in the shopping basket for this round of user testing, we would still meet our goal. And, most importantly, we could still go ahead and do that user testing we were working towards.

Sometimes, this is easier said than done, though. Once in production, it’s easy to slip into being more reactive, having to address a lot of small, diverse issues where it is hard to summarise what we’re trying to achieve in a clear statement. Sometimes, we may be able to group things together into sprints that make sense. Sometimes, though, we just have to live with quite a mixed bag of backlog items. And, it might even be that just because we built the product using Scrum, it doesn’t mean that Scrum will be the best framework throughout the whole lifecycle. Other approaches are available!

A proper task breakdown is time well spent

4. A proper task breakdown is time well spent

I love physical Scrum boards and I have created some really nice-looking ones, if I may say so myself. However, in the cases when the task boards were focused on user stories, what often happened was that cards moved into progress on the first day of the sprint and then sat there for the rest of the sprint, while each stand up consisted of people saying “Yesterday I worked on this story, today I will do the same, no impediments”.

The team creating a sprint backlog of more granular tasks, each taking no longer than a day or so, really does make a huge difference. Not only can the initial discussion about what tasks are needed for completing a story often be useful in itself as it helps getting ideas from other team members and surfacing misunderstandings about the story. It will also make it a lot easier to share tasks between team members and for the team to judge in the daily scrum how they are progressing towards the sprint goal. Awesome!

Efficiency and effectiveness are two different things

5. Efficiency and effectiveness are two very different things

Lastly, one crucial realisation for me has been that it is quite possible for everyone on a team to be incredibly efficient, completing a lot of work in the shortest possible time, without making much progress towards their goal. It all depends on what work they they are completing.

Somehow, it always sounds quite convincing at the time:

“There’s a lot of testing to do in this sprint but there is not a lot of dev work. Let’s add a few more stories so that the developers have something to do.”

Fair enough, let’s make the most use we can of everyone’s skills. Never mind the fact that we’d have no chance of actually completing those stories in the sprint, as we don’t have the capacity to test them and the testers will be behind from the start in the next sprint.

“Breaking this big story down into small, vertical slices is just causing a lot of overhead. It’s much more efficient if we do the work on the back-end this sprint, the front-end next and then the testing.”

It’s just a shame that while building the front-end, we realised that half of the fields coming from the back-end were unnecessary and that some of the capabilities we needed were missing. And it wasn’t until the third sprint review, when the stakeholders finally got to see anything, they pointed out that we had completely misunderstood what they needed in the first place.

“I’m taking a bit longer to complete my task because I’m adding in the capabilities we need for the June release while I’m in there.”

Pity that the priority changed and we didn’t end up building any of the things we were planning for the June release, so that was all a big waste of time.

“We need the developers to focus on coding, so let’s have the BA do all the backlog grooming on their own.”

Except that we might realise in sprint planning that the stories aren’t even technically feasible. Or we end up having a sprint planning meeting from hell, taking us four hours to explain, discuss, rewrite, estimate, split and re-estimate the stories.

“Let’s make sure that every story in the backlog is granular and detailed enough to be worked on, before we start development on the project.”

Great idea! That is if we don’t have anything better to do than writing acceptance criteria for stories that will have changed by the time we get to them, or will be reordered in such a way that they no longer make sense. Or, quite possibly, be completely de-scoped if we run out of time or, god forbid, someone has a better idea for what we should deliver.


As this blog post comes to an end, I need to find some kind of general conclusion from all of this and I realise it’s actually quite easy:

All the parts and principles of Scrum are there for a reason and when all things are brought together, Scrum has a good chance to help the team to be highly productive. However, if we leave anything out, the balance is lost and we are much less likely to get the result we want.

That said, I want to finish on the note that Scrum really isn’t particularly prescriptive (despite what some say) and there is still a lot of flexibility and things you can try while still staying true to the principles. Always look out for what could be done better, come up with a hypothesis for how and try it. Inspect and adapt. That’s how we improve and learn. I sure have!

I first published this post 16 May 2016 on my blog on Medium.

How to Treat Unestimated Product Backlog Items

Planning poker estimation question mark

We all know that a product backlog is an ordered list of items we’re expecting to deliver, and it includes the estimate of the required effort to deliver each one of these items. We also know that only the team may estimate the items in the backlog. The Scrum Guide is very clear on this:

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

So what can ScrumMasters or product owners do when new items have been added to the backlog, but they haven’t yet been estimated? If we treat them as being 0-story-points big, we would be assigning them the only size we’re pretty sure they aren’t.

It is important that, as ScrumMasters, we aren’t tempted to put our own guesstimate on a story. We’re not allowed. Only the team is allowed, remember? Unless we’re doing the work, our estimates don’t count, regardless of whether it seems to be a trivial story and we’re pretty sure that the team would give it, let’s say, 2 points.

The most obvious reason for this is that it’s quite likely there will be challenges that we, as nondevelopers, can’t predict. Maybe this story touches parts of the code base that are horrible and unmaintainable. Maybe there will be a significant refactor needed as part of the work. Maybe the needed data isn’t available from the application programming interface that the application is integrated with, and so on.

Also, if we’re in a role in which we are keen for the story to get delivered quickly — for example, a senior stakeholder might be chasing us — we may be tempted to give the story a lower estimate than a developer would just so that we can make it happen more quickly (hint: we can’t).

Instead, let’s consider the following:

Why is there no estimate yet?

Has the team refused to put an estimate on the story? Did they say they needed to better understand the requirements and/or work involved? In that case, bringing a spike of the story (or a part thereof) into the next sprint might be a good way to make things clearer. Another option is to try to break down the story into smaller, better understood bits that are easier to estimate.

Occasionally, the team might also feel too busy to spend time estimating upcoming work. If so, have a look at why. Best case: The problem is temporary, in which case we can hopefully just hold off with the estimation for a week or two until things are back to normal. If it’s a consistent problem, we will need to find some way to allow the team to work at a more sustainable pace.

Do we really need an estimate right now?

Sure, the backlog is supposed to contain estimated items, but, in practice, we can often work around the absence of estimates for a while. For example, are we trying to predict what’s likely to be in a release far into the future? For now, it might well be good enough to just say something like, “In our experience, each major release tends to take the team about eight sprints. Here are some things we might be looking at in Release 5. The scope will get clearer closer in time, when we look in more detail.”

What is the cost of getting it wrong?

It is also important to consider the cost of getting the estimates wrong. If it doesn’t matter too much, we could go ahead with pretty much whatever method we like. We could always revise the estimate later. However, if important decisions are based on these estimates — like the scheduling of an expensive marketing campaign — we are likely to regret later that we didn’t take the time to make sure that the estimates were sufficiently reliable.

OK, it seems as if we’re clear that only the team can estimate stories and that we sometimes need to wait in order to get those estimates. Nevertheless, is there anything we can do in the meanwhile? For example, if the sprint has just finished and we’d like to update the release burn-down, then just ignoring the unestimated stories or waiting a few weeks might not feel like the best option.

Here are a few possible approaches we could take in the meanwhile, in order of increasing uncertainty:

Get only a couple of team members to estimate the story

Ideally, we want the whole team to estimate each story, because we don’t know who will eventually be working on it. It’s possible that someone will think of something that would affect the estimate that the others hadn’t thought of. Finally, just the act of talking about the story with the team is a good way to spread knowledge about the upcoming work.

If getting the whole team to estimate a story doesn’t feel like an option, just ask a couple of members of the team to estimate it for now. By asking at least more than one person, we will still get some of the benefits we’d be getting if the whole team were estimating.

Assume that the bits of a split story add up to the original story (but be aware that they might not!)

If a story has been broken down into smaller stories, and the original story had an estimate, it seems reasonable (but rarely entirely correct!) that the estimates for the parts would add up to the estimate of the original story. Depending on what we need the estimate for, this might be good enough for our purposes until the new stories can get properly estimated.

Assume that each unestimated story is of average size

A third, slightly more risky approach is to assume that each unestimated story is as big as the average story in the backlog. My team’s stories are, on average, 4 points big. If we add 5 stories to the backlog, chances are that we have added 20 points. It could be more, it could be less; but until the stories have been estimated, I have found it to be a reasonable guess. If using this method, we should err on the side of caution. It might be tempting to say, “All these stories are averagely sized, except this one, which is just a text change, so I’ll assign a 1 to it.” Our average will already include these small stories. On the other hand, don’t be foolish and assume that a new epic is the size of an average story.

To summarize: There really isn’t any shortcut that, as a product owner or ScrumMaster, we can take to make sure that each story has an estimate without getting the team to estimate it. There might, however, be some temporary work-arounds we can use until we get actual estimates. Used with caution, these can give us some indication for how much work is remaining on a release, but they can never replace the need for the team to estimate the stories.

Note: There is, of course, a completely different question: Do we need estimates at all? This is a wholly different discussion, outside the scope of this article, so use Google to search for #NoEstimates if you want to read more about that.

This post was first published 18 February 2016 on the Scrum Alliance website. Hence the American spelling! 

Check-in exercises for agile retrospectives

Check-in exercised for retrospectives

Using a quick check-in exercise is a great way to start a retrospective. Not only does it let the participants warm up and get into the mood for the retrospective but it also allows you as the facilitator to make sure you haven’t misread or misunderstood the mood of the team. If you come to the retrospective prepared to explore some particular problem you’ve observed during the sprint, and have designed the retrospective to dive deep into this issue, the check-in allows you to make sure there aren’t bigger, more burning issues.

While repeating the same check-in sprint after sprint would allow you to track trends, I find it much more useful to avoid retrospectives getting repetitive through having a selection of exercises to vary between.

The easiest check-in you can do is probably to ask the team to rate the sprint on a scale from 1 to 5 but there are many check-in exercises that follow the same, very simple pattern:

  1. Each participant individually pick some option that represents how they feel about the sprint
  2. When the participants reveal their choice (typically through putting a sticky note on the wall) the explain very briefly, in a sentence of two, why they picked the option they did.

Some things to keep in mind:

  • As a facilitator, it is important to move things along swiftly during the check-in exercise. Don’t let the team dive into a discussion. Just let everyone explain their choice. There will be plenty of time to discuss later.
  • Resist the temptation to express your approval or disapproval of what a participant says. The participants will go one after the other, most likely without the need for you to say anything at all, but if you need to, stick to a neutral “thank you”, “who’s next” or “anyone left to go?”.
  • Adjust the check-in to the conditions. If your retrospective is intended to take 3 hours, you can allow a bit more time for the check-in but for a shorter retrospective, you will want to use a quick exercise so that you get as much time as possible for the main part of the retrospective.

Due to the time constraints, I tend to avoid exercises including too much drawing or thinking. Here are some of the check-in exercises I use most frequently (many of which I’ve borrowed from the fantasically useful site Retromat):

Rate the sprint

Rate the sprint check-in

Ask the participants to rate the sprint on a scale from 1 – 5 with 1 being awful and 5 fantastic.


Histogram check-in

This is basically the same exercise as the previous one but with a more visual result, which could be particularly useful when doing a retrospective with a large group. Place 5 sticky notes numbered 1-5 next to each other on the wall and let each participant place an empty sticky note above the number of their choice, creating a histogram (or bar chart).

Make a stand

Make a stand check-in

This is a further variation of the above. Rather than letting the participants place stickies, let them place themselves! Create a scale on the floor through placing a piece of paper with the word “Awful” written on it at one side of the room and one with “Fantastic” at the other and ask the participants to place themselves on the imaginary scale. With the right group of people, this can be good fun.

Draw a smiley

Draw a smiley check-in

Either you can simply ask the participants draw a smiley on a sticky note or you can prepare a flipchart with emojis and let them choose one by placing a dot (or an x).

Weather report

Weather report check-in

Prepare a flipchart with weather symbols and let the participants choose one. Or ask them to draw their own.

Pick a word

Pick a word check-in

Ask the participants to describe in one word how they felt during the sprint.

Target practice

Target practice check-in

Draw a dart board / shooting target and let the participants mark how far from a bulls eye the sprint was (or download my printable template).

Pick a card

Pick a card check-in with Dixit cards

Ask the participants to choose a card. It is possible to use a pile of postcards or print pictures off the internet but recently, I have been using cards from the board game Dixit, after being intruduced to them at a recent Scrum Gathering. Their abstract, evocative and very pretty pictures are perfect for the purpose.

Scrum explained in 500 words

Scrum framework overview

Agile methodologies accept that in most cases, change is inevitable during a project. We cannot predict exactly what will happen along the way. Instead, we collaborate with the users and let requirements and solutions evolve and plans adapt as we learn more.

One of the most common agile frameworks is Scrum, where we work in short iterations (1 – 4 weeks), called sprints. At the end of each sprint, the team delivers a potentially shippable release of the product.

scrum team consists of a product owner, a development team and a scrum master. The development team is small (3-9 people), cross-funtional (contains all skills needed to deliver the product) and collectively responsible for the work in the sprint. They self-organise to do their work in the most efficient way.

The product owner represents the users and customers and decides what to deliver. One of their responsibilities is to maintain the product backlog, the prioritised list of features we intend to deliver. Requirements are created just in time, so items at the top of the backlog, which we intend to develop soon, are more granular and specific than those towards the bottom.

At the start of each sprint, we hold a sprint planning meeting where the product owner and the development team agree a sprint goal based on the top product backlog items and what is achievable. This goal is fixed for the duration of the sprint and cannot change, unless the sprint is cancelled which is very unusual. In the sprint planning meeting, the development team also create their sprint backlog, the list of tasks they need to complete to meet the sprint goal. The sprint backlog often takes the shape of a physical scrum board with index cards or sticky notes representing tasks, placed in columns to reflect their status, allowing everyone to quickly see what’s left to do and who is doing what.

Every day, the development team holds a daily scrum meeting where they organise their work for the day. Typically, this is done through each team member answering three questions: What did you do yesterday? What are you doing today? Is anything blocking you? This meeting should never be longer than 15 minutes and, to keep it as short as possible, most teams stand up throughout the meeting.

The scrum master makes sure that the scrum team is as productive as possible. They do this through ensuring the product owner and the team follow the scrum principles and through removing any impediments preventing the team from meeting their goal.

At the end of the sprint, a sprint review meeting is held where the team demonstrates the items completed in the sprint. Stakeholders are invited to give feedback and the product owner may add or reorder items in the product backlog based on the outcome.

After the sprint review, the team hold a sprint retrospective where they look at what went well and how they could improve the way they work together in the next sprint.