Working out your team's velocity

How does your team know how much work they are able to commit to in a sprint?

If they're anything like my team, velocity can often be less of a science and more of an art, or rather, a finger in the air/gut feeling that there's too much or too little work in the sprint.

We wanted to change this, and learn more about our velocity, so the first step was to at least get an idea of some basic metrics. I find it hard to remember, but there was actually a time before we estimated stories and gave them story points.

When the team was first formed, we tried estimating in hours, and eventually shifted to story points using planning poker (because they are more abstract, allow for mutual calibration and take into account effort, complexity and time).

We tried pointing for quite a while before we started to arrive at a more consistent velocity. It took about 14 sprints before we had an understanding of what we were capable of as a team.

Our velocity (the tall column on the left is a fix version where we threw legacy stories to clear them out).

But we still had the issue of not knowing exactly how much we could commit to in the next sprint, because whenever we used the previous sprint as a guide to capacity for the next sprint, there were always mitigating factors and "exceptions" why the velocity was higher or lower.

Finally, we came up with 2 practices which seemed to make a big difference.

1. Rather than looking at the last sprint the gauge estimated velocity for the upcoming sprint, take the average of the last 3 sprints and this will give you a better idea of how your team performs over time.
2. Estimate take taken for absences such as Public Holidays, Vacations and Training. Story point these absences as you would for a piece of development work, and you will begin to take people's time away from the office into account when determining capacity for the sprint

What techniques do you use in order to understand your team's capacity for a sprint? Do you estimate in hours? Or story points? Or both?

There's value in a mid-sprint checkpoint

We do 2-week iterations, generally with a demo at the end of the sprint, and we're fairly strict about only allowing potentially shippable code into the demo. This can mean that stories often carry over into the next sprint because they haven't completely met their DONE criteria, even though the bulk of the development work has been completed.

We don't count points for stories until they have been completed, and yet we limit our points commitment during sprint planning -- which can sometimes mean that the carry-over stories take up the bulk of our points commitment. When this happens, we are left in a situation mid-sprint, where most of the cards have traveled across the wall into the DONE column, and we still have capacity left in the sprint.

When this happens, in theory, the team is meant to pick stories from the top of the backlog (which is, in theory, meant to be in priority order and with story points already estimated). The reality is that we try our best to keep that top of the backlog in order, and often it's just not ready to go. This can mean that the developers start to 'cherry-pick' stories that they feel like working on, rather than adhering to the priorities of the product owner.

We've just experience this situation in our last sprint, but we did something a little differently, which seems to have made a big difference: we held a mid-sprint demo, which we used as a checkpoint with our product owner, to make sure we were on the right track, do some user acceptance testing, and set the course for the remainder of the sprint.

In this case, we were building an admin tool, for use by the product owner. What we discovered during our mid-sprint checkpoint, is that the tool as it was currently built, was only usable on a developer's sandbox machine, required a whole lot of configuration and setup, and was generally fairly clunky. It was a (dare I say) painful session for all involved, which lasted nearly half a day, but at the end of it, we came away with valuable feedback and a stack of new cards to add to the top of the backlog.

Now, I'm not necessarily advocating adding tickets into a sprint midway through. Instead, what we had created was a clean, prioritised and estimated backlog which the team could go to once they had burned through what they had already committed to.

And it this case, it worked very well. In the end, we completed all of the carry-over work from the previous sprint (about halfway through the sprint), had our mid-sprint checkpoint, then completed an additional approx. 25 points over our usual velocity. By the end of the sprint, we had an admin tool which was very close to the finished product, certainly usable in a pinch, and can be polished in the next iteration.

Measuring Agile values

I'm really very proud of the team here, in that I think they've done a lot of work over the past 18 months to adopt the Agile principles and the 'characteristics of a high performing team'. One of the most useful exercises I've done recently is to actually get the team to rate themselves on these values and characteristics. This works, not only because they are able to see a reflection of their own performance, but also because I can share these metrics with our new departmental head, as an indication of how the team is doing.

The graph above represents the outcome of the team rating themselves last week. The task was to read through all of the values and then rate how true they are for the team on a scale of 1 to 5, with 5 being outstanding. Looking at the graph, I think the team thinks they're doing pretty well, and it also highlights areas that they believe they're particularly good at, such as:

• Openness
• Empowerment
• Consensus driven

Those values really ring true for our team, and when I showed them the graph, it felt authentic to them, as well.

If you want to do an exercise like this with your team, here are the Values and Characteristics.

Scrum Values
Commitment – Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.
Focus – Do your job. Focus all your efforts on doing the work you’ve committed to doing. Don’t worry about anything else.
Openness – Scrum keeps everything about a project visible to everyone.
Respect – Individuals are shaped by their background & experiences. It is important to respect the different people who comprise a team.
Courage – Have the courage to commit, to act, to be open, and to expect respect.

Characteristics of a High-Performing team
1. Self-organising rather than role- or title based.
2. Empowered to make decisions.
3. Believe that, as a team, they can do anything.
4. Committed to team success, rather than success at any cost
5. Team owns its decisions and commitments
6. Trust (rather than fear or anger) motivates them
7. Consensus driven, with full divergence followed by convergence
8. They live in a world of constructive disagreement

Please rate our team on a scale of 1 – 5, with 1 being lowest and 5 being highest.

Agile retrospective: How cross-functional are we as a team?

In this exercise, we listed out all of the technologies and skills that we think are used and needed by members of our team. We then took turns graphing our skill sets and arrived at a picture of how cross-functional the team is, highlighting areas where we are low on certain skills and discussing ways we can share knowledge to become more cross-functional.

Agile retrospective: The Happiness metric

I included the Happiness Metric exercise in our sprint retrospective yesterday, and I think it was fairly well received. To my great pleasure, the team seems to be, generally, a fairly happy bunch.

Here's what we did:

In this exercise, we answered a few questions about happiness, rating on a scale of 1 to 5 (5 being ecstatic), how happy each of us are with our team.

On a white board, write four questions:

1. How happy are you with your team right now?
2. What is working best for us as a team?
3. What is working worst for us as a team?
4. What we could do right now to make us happier?

Explain to the team that this information is to be kept private, for the use of the team only, and not to be reported elsewhere or to their management.

• Have the team write a sticky note, rating their answer to question 1.
• For each subsequent question, they can write as many notes as they want and place them next to the questions.
• Review the notes, group them together to find common themes, and agree on any actions to take away which might increase team happiness.

This exercise can be repeated periodically, and can be translated into a google docs spreadsheet which the team can keep constantly updated with their levels of happiness. The benefit of this exercise is to uncover easily fixed issues which make team members unhappy, as well as find issues which effect several members of the team, and nip problems in the bud early.

A way to encourage pairing

We are a team of software engineers, web developers and devs-in-test, and we have begun to realise that our velocity increases (and so does morale) when the whole team is pulling toward the same goal. This can be a particular challenge, when the goal of a sprint is heavily focused on a single discipline, say, a feature that's primarily work for software engineers, which leaves the web devs looking for other things to concentrate on.

In our quest to become a more cross-functional team, and to eventually get to the point where we are a group of well-rounded generalists who can pick anything from the backlog, we have been trying to think of ways to increase our learning across disciplines.

A good way to achieve this is through pair programming with members of the team that you don't normally pair with, and to encourage this rotation, we had a great idea from Rob Chatley.

The Pair Stairs

Track who has paired with who this sprint

The idea here is that each person ticks the box for the person they last paired with, making sure that they spend some time with everyone in the team at some point during the sprint. It doesn't have to be a whole day, just an hour or two will go a long way towards understanding what that person is up to.

Ideas to liven up your Agile retrospectives

For almost a year, I led my team in a standard method of sprint retrospective:

1. Draw happy and sad faces on the board
2. Draw arrows: up, down, equal (to represent "do more of, do less of, keep the same")
3. Everyone quietly reflects on the sprint and writes their thoughts on sticky notes
4. They then stick the notes by the icon that fits the most, happy, sad, keep the same, etc
5. We all then gather round and look at the notes, taking it in to find common themes
6. The notes are then grouped into rough themes
7. Actions are derived from the themes and (sometimes!) assigned an owner
8. We all wander back to our desks, somewhat satisfied that things will change in the next sprint
9. Outcomes are documented on the wiki with photos of the whiteboards

On one hand, I have to commend the team for sticking with the retrospective process, sprint after sprint, rather than abandoning it, which is what a lot of teams tend to do. Retros can be the first thing to go in Agile teams, as they can feel like a waste of time, especially if no actions come out of them.

On the other hand, we let the process get stale to the point where it seemed like a robotic action to go through every other week.

It was time to shake things up and do the retros a little differently. We decided to learn some tricks from another team, and try part of their retro method.

In this exercise, you go around the room and everyone states:

1. How they rated the sprint on a scale of 1-5 with 5 being best
2. List 3 words that describe the sprint for you

Everyone rates and describes the sprint

In this exercise, everyone takes a marker and makes a graph of their happiness throughout the sprint. It allows you to see where blockers had an impact on team morale or where one person is feeling particularly frustrated by something.

 

A visualisation of team happiness

We then finished the session with the exercise to understand common themes:

Uncovering common themes