Why Scrum teams between 3 and 9?

We all read the Scrum Guide but have you ever wondered why the band of sizes that is prescribed?

Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.

Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.

Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.

Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.

Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.

Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.

Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.

Counter measures we tried:

Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.

Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.

Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.

Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.

Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.

Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.

In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.

We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.

One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.

My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.

Visualising Sprint Planning

I heard a fantastic thing today:

"Well, we have a velocity of about 40.... so we should be able to handle three 13 point stories"

Let's explore how this might work using some pictures.

We can start with a box representing our sprint. We start on the left and finish on the right, exactly like a timeline. We have 8 developers on the team, who pair the majority of the time so we can see the sprint divided into 4 parallel streams:

As I blogged about previously, I know my team deliver 13 point stories 10-13 days based in previous history. Visualised, this would look like:

Not a great start.

For the purposes of this blog, I'm going to imagine we have sorted this issue and the team have a track record of delivering 13 point stories within our sprint window of 10 days. So going back to the previous statement, we can view the sprint like this:

First obvious issue, what would the last stream be doing? OK, so we had some spare capacity - according to our velocity we had 4 left over so we could bring in a 5 point story and still be OK. Five point stories are taking about 7 days:

We have a little slack, which is never a bad thing. However something more sinister is going on - these developers will not have many options to deliver this work.

The pairs on 13s will be stuck with that story from beginning to end. Everyone else has a similar problem.

We have 4 stories in play. 3 will probably finish around the same time, which is right at the end of the sprint. We only have 2 developers at the end to help get these stories across the line as far as testing goes. One developer on each story could mean one story is sacrificed.

The numbers and stories 'fit' but this is less than optimal and still pretty scary.

If we can, we aim to finish stories mid sprint. This allows us to mix up the teams skills or to add resource to another story if required. In the previous example, although we could try to do this we risk not delivering the stories at all.

So if we could break down the stories a little, we could also assess risk and decide when to start a story. In the following example, we have a big 13, two 5's and a 3 all in progress:

If everything pan's out the guys working on the 3 will finish in time to help out with both of the 5's or start another story. Alternatively, they could help out with the 13 if we feel there is more risk in that not being completed.

With the 2 fives being complete, we could swarm on another story that we tasked out specifically to allow more people to work on parallel or we could mix up the pairs and pull in 3 smaller stories - probably a 2 and a pair of 3's might fit if we look over our lead times. Merging 2 of the streams and working on 1 story would lower WIP, which reduces lead times which is another option.

Alternatively, we could benefit from a bit of slack and allow the team to evolve their development practices. Seeing that they are no longer working from beginning to end, we have that option also.

All these options start for us in prep and planning. Our choices on how we break up and task out stories allows us to plan how we are going to deliver that work. Just relying on numbers is way to simplistic. Knowing a bit about your leadtimes gives you pretty powerful ways of visualising how the sprint should pan out.

Like photos, sprint composition is an art

A while back I started looking at metrics used in Kanban to better understand some of the patterns I was seeing in my sprints. The change from looking at a sprint velocity to looking at leadtimes for individual stories has been an eye opener.

In particular, I started to look at the composition of sprints rather than just trusting a velocity. The problem I have with velocity is the perceived safety it provides. Estimate stories, add the totals and when you reach something near your velocity you should be good to go.

Imagine this: we have a velocity of about 40 so we should be good to take in four 8 point stories and still have a little room right? This is where leadtimes start to give us a little more information.

My team is quite large, having 8 developers and 2 testers. We generally work in pairs so I see this as 4 parallel development tasks with an additional 2 testing streams. The team work on development and testing in parallel as much as possible - joining up is still a little fun but we get by.

I know from looking at my leadtime data that the average leadtime for an 8 point story is about 6 days. The worst we have turned a 8 point story around in is 9 days, with 4 days being the best. We work in a 2 week sprint cycle, which is realistically 9 days once we take out planning and other ceremonies.

Working with the averages alone, to have a 50% chance of completing all the 8 point stories in the sprint, we would need to start them all by the 4th day of the sprint. If we wanted this to increase to a 85% chance, the leadtime increases to 8 days meaning we would need to start them all on the second day of the sprint.

Here are some of the problems this could introduce:

Higher WIP: With 4 stories that all need to be started within a few days of each other, we force a higher WIP. Higher WIP means longer lead times.

Loss of fluidity/options: With 4 parallel work streams each using a pair of developers, we might find it hard to move people between tasks. We basically end up with a static pairing from the beginning of the sprint to the end. This limits our options or introduces waste where we have to move people around e.g. illness or a specialism that we have not shared yet.

QA 'tsunami': There is a risk that all 4 stories will need QA at around the same time. This might create a bottleneck in testing and slow throughput. If you had some flex in the team, you could get the developers to help with the testing - in this scenario that is probably not an option.

The composition of how that 40 points is reached is as important as the number itself.

Having a mix of smaller and larger stories creates more opportunities for the team to collaborate on delivery. Having stories finish regularly throughout the sprint allows the team to find points at which they can mix up their pairing or help out with other stories in progress. Having this flex allows you to shift responsibilities around the team to help keep stories moving across your board.

If you do have larger stories then look to create tasks during planning that allow a larger number of people to work on the story at the same time. This helps lower your WIP and decrease the leadtime for the story, which will give you more choices as to when you can start the story during the sprint.

Be careful not to overload a story - just putting more people on a story will not make it progress faster, it needs to be a part of the plan.

This might go back as a far as preparation where you could choose to break up stories a little further to allow them to be worked on in parallel during the sprint. You might need to negotiate on the independence of the stories you have broken down but it might save you from negotiating on what you can deliver.

Describing value using Situation Cards

EDIT: I have since found out that Situation Cards are really similar to Social Story and Comic Book Conversations.... read more here

A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.

Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.

Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.

We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:

In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.

You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.

This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.

The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.

We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.

We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.

These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.

Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)

Size (sort of) matters

Recently, I have been keeping a small set of metrics on the stories from my team. I started with simple dates so I could look at leadtimes - the time taken from when we start a story to when we deliver it.

With just these 2 dates you can do a lot! A lot of this came from looking over what was presented by Mattia Battiston at a meetup not so long ago. In particular, I was interested in his observation that there is very little correlation between story sizes and leadtime. This is something I have battled before so I was interested when my own data showed a very similar pattern:

Looking at this you could infer that a 2 point story might take as long as n 8 point story, which is hardly useful. What I missed for a while is the upper bounds across all the story sizes. We have a couple of anomalies at the top but the vast majority are within 10 days - which you should know is the length of our sprints.

That caught my interest. Although we cannot say with any sort of accuracy how long a 5 point story will take - in this example the longest was 26 days and the lowest was 4 days - we can say that 95% of 5 point stories can be delivered within 10 days or less. You can repeat a similar statement for story sizes 8 and below.

So maybe we should revise what we are expecting from our estimation by the team. What we are very good at doing is working out what can deliver within our sprint window. What we actually want to know is how many stories we can expect to be delivered if we want to use this to forecast, which is our throughput.

For me, looking at leadtimes influenced how we were working on and preparing stories. Littles Law describes how we should see a lower leadtime if we lower our WIP. We think more about how more of us can work on a single story, this often starts in prep. We open less and this lowers WIP, decreasing leadtimes.

Having a leadtime which only just fits in a sprint window means we have limited options on how to plan the work in the sprint - we have to start everything on day 1. This would mean loosing fluidity - everyone would be one a single story from beginning to end. Not many options for us at all.

Lowering leadtimes by a few days gives us some flexibility in when we can start stories. We use our story points to influence when we start on things. Larger stories might need to go first but smaller stories run in parallel so that we can deliver throughout the sprint rather than everything at the last minute, which would probably create a bottleneck with testing.

For me the sizes of stories begin to matter less and less. They serve their purpose during prep and planning and help us get to the answer: "Will this fit in our sprint?". When we see a 13 we look to break it down further since we can see it is rarely delivered in less than 10 days, which does not give us enough options. 

If we bring something in mid-sprint, we can look at the previous leadtimes and give a percentage "75% of previous 5 point stories have been completed in the time we have left" allowing us to make a commitment with some accuracy on success.

There are many more interesting things you can gleen from leadtimes and some basic spreadsheet fun, Mattia's presentation is a great place to start.

My Retrospective on my Retrospectives

I have been doing regular retro's for about a year since I changed direction career-wise. I have recently been looking over how my style has changed and looking at why these changes came about.

Working with an experienced Agile coach has certainly been the catalyst - Helen Meek has pointed out many areas of improvement which I have been gradually working on over the last few months. Other inspiration was from an amazing talk from a lady who works with kids on the Autistic spectrum called Gina Davies.

She describes how she centers attention around a box. There is something different every time in the box and the kids she works with respond to this by sitting and waiting to see what happens next. You don't realise how effective this is until you see some video - kids with ASD don't get 'waiting' but after a relatively short amount of time, they start to participate and want to wait to see what happens next. The box is 'magic' - something new happens every time.

So this got me thinking, what's my 'magic box'? The obvious answer is the retro. It should be fun and engage the team. It should be something we all look forward to. Here's my observations on things that I have changed over the last 6 months:

Keep it Fresh - One of the key things I have tried to uphold is to never repeat the same retrospective with a group. I mix up sections of the retro or come up with a dedicated retro to target a specific area that the team needs to improve on. Sometimes I am inspired and come up with something completely new, other times I spend some time putting something together using the awesome Retromat.

Experiment - Each team is different. Different styles and techniques fit with some teams and are lost on others. Experimenting with formats lets you continuously improve getting the team involved and engaged. You also learn what works for a given situation - your retro style and format may well change depending on the sprint and team morale.

Sit back, relax - Helen encouraged me to sit back and watch the team rather than stand up and direct. Sounds easy but your team may now be a bit lazy! By you sitting back 2 things will happen - first your team will need to get more involved and second you can observe your team and start actively getting people involved. Helen encouraged me to direct, rather than lead which is a really nice way of seeing it.

Stories not Events - I have noticed that the events that stick out are usually the bad ones. These are usually the ones brought up with allows for improvements but does not help with celebrating successes. We should be pepped by the end of a sprint! Using timelines you can encourage storytelling, allowing you to replay a sprint from beginning to end. You can journey through the sprint, looking at what happened so you can see both the good and bad points.

Be prepared! - I spend as much time prepping a retro as doing one, if not more. Since I vary my format, I have to spend some time thinking about what I am going to do. This is a good thing and the team deserve it. Playing out the same retro might feel safe but I should imagine the team dread it after a few months. Dedicate time to preparing your retro, fitting it in with the teams personalities and requirements.

I'm sure there is more but these are the ones I have had on my mind recently. Enjoy!

Reference Conversation

So, I have this problem. I find it very hard to start conversations. This has never really been a problem, I put it down to how I'm wired. Just recently, I have cause to think this is holding back my career progress so I have been working on understanding why and finding a solution or workaround.

First, I looked back and realised that fear had a big part to play. I have a tendancy to build up the conversation in my mind, running scenario after scenario in an attempt to control the conversation when I have it. In reflection this creates a negative feeling around the conversation so I shy away from starting it in the first place.

The build up also means that if I do start a conversation I am already apprehensive about it, which I am pretty sure the other person picks up on. Bad news all round really.

Now, I use 2 things to help break this cycle. The first is to think only about what the conversation is about and how I let the person know that. Seems simple really, I just work out how I open the conversation e.g if I am just checking in, I let the person know that in the first few seconds so they can relax.

Even if this is something that the other person might find difficult to talk about, I realise that I only need an opener - something is worrying me, this is why, now lets find a solution. I find this far less scary to think about.

This got me some of the way in that I could shut down a thought process by recognising it as daft from the outset. Once I had an opener, I could put it to one side as there is nothing left to think about.

Then I needed to find a way of countering the fear of starting the conversation, which felt like a learned response at this point.

Taking a cue from story planning, I came up with the idea of having a reference conversation. This gave me something I could refer to in the lead up to a conversation if I was feeling anxious about it. Similar to how we would use a reference story in planning, I would compare the type of conversation I was going to have with my reference conversation in help me recognise that it is really much less than I had built it up to be.

I use my reference conversation at any point that I am holding back from a conversation. If I am putting off booking it or starting it, I review my opener and remove my fear by comparing with my reference conversation.

For me, my reference conversation is one that I would not have the words for. It is one that I can think about and realise that all mine are trivial in comparison. As simple as this technique is, it has helped me move on and focus on having the conversation itself.