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

The "How would you spend £1000" prioritisation exercise

We did a 3-hour session the other day to come up with requirements for a open tender procurement, with a large group of stakeholders from around the organisation. Each stakeholder was coming from a very different angle on the problem, and the challenge was how to arrive at a set of commonly agreed requirements in priority order, with some idea of how they would be scored in the tender process.

The exercise we ended up doing was actually pretty fun and a good way to lighten up a long session.

Here's what we did:

1. Before the session, collect some play money (either from a board game or create your own) in a number of denominations
2. Once all of the requirements are written on index cards, lay the cards on the table
3. Give each participant their "budget" (in this case, our budget was £1000, divided into £200, £100, £50 and £20 notes)
4. Get everyone to "spend" their money on the requirements, piling their money on top of the index cards
5. Send the group on a coffee break and tally up the piles of money on each card
6. Arrange cards in descending order of money spent on them.

By the end, we arrived at a linear priority list of requirements. Some were surprised by which requirements floated to the top, which generated useful discussion and thoughts on how we can expand the sub-criteria for those categories.

How do you do your priorisation exercises in a large group workshop?

Measuring team happiness

At this sprint's upcoming retrospective, I plan to try a new exercise, involving measuring the happiness of the team.

We've attempted this in the past, with everyone drawing a graph of their mood throughout the sprint. This proved fairly useful in identifying factors (often external to the team) which brought down morale during the sprint.

The massive drop in morale was when our application failed load test which blocked the live release.

We tried this method for 6-7 sprints, but eventually the graphs fell out of favour because nobody felt it was giving us that much value in terms of concrete actions to resolve issues and improve morale.

So, this time round, I want to try a slightly different tack, the Happiness Metric.

I'll ask the team 4 questions, and get them to write their responses on sticky notes:

1. How happy are you with your team?
2. What feels best right now?
3. What feels worst right now?
4. What would increase your happiness?

I'm actually considering making a little Survey Monkey mid-sprint to gauge the team's happiness, and have something to compare it with at the end of the sprint, but I'm not sure how valuable that will be.

The Kanban Coffee Shop

The principles of a Kanban, as defined in David Anderson’s Kanban, are:

• Visualise work
• Limit work in process
• Measure and manage flow
• Make process policies explicit
• Use models to recognise improvement opportunities

Kanban barristas

A couple of weeks ago, our team found out how similar a Kanban software team can be to a coffee shop. The guys from Agility in Mind did a great exercise with us where we were suddenly morphed from a development team into a group of (comically terrible) barristas.
 
They set up stations around the room for:

• Customer orders
• Coffee shots
• Milk/foam

With a few constraints in place, we were then set to work on creating a flow for customer orders. Feedback from our coaches was that it was an incredibly painful thing to watch.  

In the first round, orders came in very fast, which rapidly overwhelmed the coffee shot station, creating a backlog. By the time the orders got to the "customer", 75% of them were wrong!

Rather than listening to the customer (who was literally standing in the corner calling out "Hellllooo??"), we instead gathered together to see how we could improve.

We added Quality Assurance as the final step in the process, and we flowed a bit more smoothly the second time around. Again, we ignored the customer's entreaties.

Finally, we gathered together and proposed a radical change: rather than handing the coffee cup from station to station, we would travel with the cup until it was complete. With this change, people went from specialists to very confused generalists, which resulted in the longest round of drinks with very poor quality for the customer. Epic fail!

Comparison of barrista work to software development

In the end, we learned a bit more about creating an efficient flow, as well as the major lesson of listening to our customer.

Ash Moran at Patchspace explains it well...

What happens from the coffee shop’s point of view is this:

• You, the customer, arrive at the customer queue, and you do so randomly (at this point, you wait)
• A barista takes your order, a list of random drinks – that is a batch of work to be done, of variable size, complexity and value
• Your order goes in a queue (at this point, not only are you waiting, but so are the drinks)
• One or more baristas make your drinks, that is, the batch of work gets processed (you’re still waiting)
• A barista hands you your order, that is, the completed batch of work

Before we go on, just reflect how similar this is to software:

• The client / business turns up with a “new idea”
• The client describes some work they want you to do (which will be of variable size, complexity and value)
• You put the request in your backlog
• At some point, one or more developers become free and turn the request into working code (which will take a variable amount of time)
• You deploy the software/deliver the code, etc

So if you can accept that an index card describing the new feature “View product listings by category” is more or less the same as an empty coffee cup waiting for a drink, the two processes become coherent.

What are your experiences with a shift from scrum to Kanban? Any ideas on how to create a more efficient flow of work?

Improvement Experiments Kanban

The team are very keen to always improve their agile practices, with many suggestions coming out of each sprint retrospective. Some of these get implemented, stick, and become part of the new way of doing things. Others fall by the wayside and are forgotten.

Improvements can be things like:

• Implement pre-dev checks to explain the work that will be done
• Rotate the scrum master role around the team to keep it fresh and ensure everyone is involved
• Create a Readiness Board to ensure stories are prepared enough to go into a sprint

We had a few excellent sessions with Matt Wynne and his colleague Rob last week, where they helped us to focus our improvements.

The Kanban board is courtesy of Agility in Mind, and was re-purposed to become an Improvement Experiments board for the team.

The idea behind the Improvements Experiments is that, rather than just a collection of "good things we should be doing", some structure gets added to the process improvement.

Here's the process in a nutshell from Matt & co:



We've already started tracking items on the board, and so far have proven 3 experiments. So it seems that we're onto something here!

Have you had any success with methods of tracking the improvements your Agile team suggests during the sprint retrospective? Please comment and share your experience.