Andrew on Agile

During my ScrumMaster certification, Mike Cohn recommended that the size of a cross functional scrum team should be between 5 and 9.  In a recent exercise, we tried splitting a scrum team three ways – 5-6 people in each team - for the next release.

At the end of last year I counted 16 people in a scrum.  For most of the release the team size averaged 12, consisting of a mix of product managers, QA, front-end engineers, software engineers and the ScrumMaster.  16?  It never meant to get that big, but with an addition here and an addition there, it did.  It was too big.

The scrums were starting to take too long, there were too many stories in the sprint for one team to truly keep track and impediments were flying around everywhere.  Risk was starting to creep into each sprint and eventually the release.

I put it to the team that they should split in half for the next release and while some members were ok, others really objected to the idea.  They felt it would generate unnecessary tension between a team that had grown strong together.

Due to the type of work within the first sprint in that next release the team worked as one again, but agreed tentatively to an unequal split (1/3 to 2/3) for the following two (and final) sprints.  It was ok, both teams had a couple of issues mainly down to the fact that they were building three applications which all needed to communicate with one another, but the smaller team certainly preferred being small.

So now they’ve split into 3.

It’s brilliant.  The teams are made up of 1-2 QA, 2-3 Engineers and a Product Manager.  The teams were encouraged to go through the agile scrum motions how they saw fit.  The smaller size enabled intense collaboration during a short planning phase, resulting comprehensive stories.  Poker and sprint planning was a breeze, less big personalities to get in the way of proceedings, and it was so much easier to keep on top of the progress during the sprint.  The software’s of high quality.  It’s done.  It contains a good level of tests and the quality of the code is great.

Now that risk is greatly reduced.  In the sprints before if something started to go wrong it could have affected the whole team.  All members would get distracted by the issue and if it didn’t get resolved and the goal compromised, the team would be left demoralised by all the drama such failed sprints bring.  Oh yeah, and the team members love it.

So if it was going good, then the team gets bigger and you start to have problems, or if you’re trying things for the first time and some members aren’t engaging, break it down.

I wanted to post this as an update to the original post on how to estimate story points using the poker planning technique and involving your QA team.

In the first post I describe how a poker planning session almost broke down when including the Quality Assurers in estimating the relative size of each of our stories.  Just to get through  that session we ended up producing one or two estimates that didn’t include the testing time.

It’s amazing how adaptable people can be.  On our second attempt, only 2 weeks later, I’m very pleased to say our session went brilliantly.  They key to this success, I feel was down to the ScrumMaster.  They took the initiative, pre-empting another possible disastrous session and clarified some of our own rules.

Last time, because both engineering and QA were unused to thinking about delivering stories to done including each other’s time, we ended up settling on the highest value either the engineers, or QA, or a hybrid could agree on.  There was very little unanimity, nor was anyone really convinced we were providing estimates to the best of our ability. 

This time we started our session by reviewing a very simple process designed for our team that the ScrumMaster had put together.  If consensus could not be reached by the first attempt at laying cards, try again.  If still no consensus after a round of discussion, try again.  On the third attempt if there was still no consensus we would settle on the highest value, as we had in the previous session.  Mike Cohn suggests in his “Agile Estimating and Planning” book to “…continue the process as long as estimates are moving closer together…”, but in the past this hasn’t worked for us hence the 3 time cap.

From there on in, the team set about story pointing.  We had about 9 stories to estimate and in about an hour and a half we were done.  Estimating for each other’s disciplines still didn’t come easy for everyone, but when someone struggled, the team worked with them so they could understand what they were thinking about.  Only once did we not reach a consensus by the third attempt, and that story had such a high estimation it would need to be broken down further.  The mood of the session was very positive leaving all present extremely satisfied with the result.

So, the first stage particular exercise to incorporate QA into our story point estimation sessions has been a success.  Yet another leap forward in our journey.

There will be more to follow on sprint planning with QA and integrating the seating plan of teams who are already co-located.

Good stuff.