Agile Games at Agile Open Southern California

Our very own Laura Powers recently participated in Agile Open Southern California, where she was interviewed by Scott Dunn. Laura talks about the power of games to help executives understand the changes they need to make in order for their organizations to become more agile.

The video was put together by Cliff Rosa of Rosa Media Productions.

Posted in agile, conferences, games, videos | Leave a comment

How Not To Be a Product Owner

I’m facilitating a certified scrum product owner workshop today. We talked a lot about how to give product requirements guidance to the scrum team. Then I shared this video.

Posted in agile, ha ha funny, videos | 2 Comments

Should Management Use Velocity as a Metric?

Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working. That’s not what it is at all. Velocity is a measure of the rate at which the team is delivering stories. If the team worked long and hard on 5 stories but delivered none, then their velocity is zero.

Because of this misunderstanding, I find managers who think that it is important for the team to work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Faced with a manager who wants to track velocity as a management metric, a scrum master needs to identify what the manager is trying to measure, and what business decisions they expect to make with that data. The scrum master can then help the manager find more effective ways to get the data they need to make their business decisions. If the manager wants visibility into how healthy the team is, or perhaps how productive they are, we can provide them much better metrics. Trying to use velocity for these purposes won’t work.

Imagine that you are on a team, and your manager wants to see the team’s velocity increase over time. This is very easy to achieve, the team can simply increase their estimates for the user stories. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule.

Velocity is a great tool for predicting what the team can deliver in the future, so long as the story points aren’t being inflated. If a user story that the team estimates as five story points today is not approximately as much work as five-point stories estimated in the past, then predictability is lost. Everybody loses.

So what is a better management metric? Number of stories delivered. It’s imperfect, as all metrics are, but it is much better than velocity. Measuring the number of stories delivered per sprint will drive a number beneficial behaviors, and gives a manager a better window into the health and productivity of the team. When a story is done, the team has delivered value to the business. This is what the business wants. Think about it. The business exists to create value, not to create busy people. When we measure the number of stories delivered, we are measuring the rate at which the team is delivering value. More stories delivered means more frequent delivery of value.

So what if we game the metric? Remember, that to game velocity the team inflates estimates. To game the number of stories delivered, the team will break their stories down into smaller stories. There are many benefits that come when the team works on smaller stories. Smaller stories are easier to understand and thus easier to implement correctly. Smaller stories will get delivered more frequently, which allows more frequent feedback. The team will get more frequent product feedback from stakeholders, so they can make more timely adjustments to the product. More frequent story completion means the team will update their burn down chart more often, and have much better knowledge and control of their schedule. Smaller stories also mean the variance in the team’s velocity, the natural up-and-down swings, will be smaller. Additionally, the more frequently the team delivers functionality to users, the more frequently they can inspect and adapt their architecture, design and technology choices. I’ve previously written about how to break big user stories into smaller user stories. Might the team go overboard with this? I’ve never seen it. I’ve worked with hundreds of teams and I’ve never once encountered a team who’s on-going problem was that their stories were too small. On the other hand, most of the teams I coach are having problems because their stories are too large.

So measuring number of stories delivered leads to smaller stories, which increases the rate at which the team is delivering value and also speeds up the various feedback loops that keep the team building the right things. Everybody wins.

Cheers,

Chris Sims

Posted in agile, project management, scrum | 1 Comment

A Scrum Master’s Perspective on Story Point Accounting

Recently, I answered a question about how to do the story point accounting when a user story spans multiple sprints. The scrum team had several user stories that were started in sprint one, but completed in sprint two. Since velocity is a measure of the rate at which the team is delivering stories, we found it best to count all the points for a story in the sprint in which it is completed.

Now let’s examine the question from the point of view of a scrum master. A scrum master’s job is to help the team improve and progress toward the goal of becoming a continuously-improving, high-performing, self-organizing, possibly-over-hyphenated scrum team.

The question is being asked because the team members are feeling some pain. They have worked hard on four stories, but only completed one. This doesn’t feel good and they are looking for a way to alleviate the pain. The quick fix is an accounting trick to give the team ‘credit’ for working on, but not delivering, their stories. This only accommodates the team’s dysfunction. A scrum master will want to help the team find and fix the root causes of the pain. In this way they may fix the problem instead of perpetuating it.

Common root causes are:

I’ve already covered what to do if the scrum team’s user stories are too big. In the coming weeks, I will examine several of these root causes and offer ideas as to how a scrum master could help the team and the organization become healthier and more productive.

Perhaps you can think of other root causes that may be at play here. Leave a comment and I’ll do my best to explore and discuss those too!

Cheers,

Chris Sims

Posted in agile, scrum | Leave a comment

Story Point Accounting Across Sprints

I recently received the following question, asking about how to account for the story points of stories that are started in one sprint but completed in a later sprint. There are some interesting things to consider here about the user stories, the scrum team, the product owner and the scrum master. I suspect the answer to this will take multiple articles, much like our recent series on splitting big user stories into smaller user stories. Let’s begin!

The Question

Let’s say you’re doing weekly sprints and this is Week 1. You believe you can accomplish 20 story points in this week, and you have stories A, B, C, and D – each worth 5 points – scheduled for this sprint. So you plan to accomplish:
A – 5
B – 5
C – 5
D – 5

You do about 80% of A, 60% of B, 80% of C, and 100% of D. If you could get partial credit, it would be:
A – 4
B – 3
C – 4
D – 5

But since you can’t count partial credit, your actual count of the points completed is as follows:
A – 0
B – 0
C – 0
D – 5

And your velocity for Week 1 is 5.

Then in Week 2 you again plan to accomplish 20 story points. We’ve done 11/15 of the work on stories A, B, and C, so there should be only 4 story points left of work to do on these. We can accommodate 16 more story points, which are represented by the next stories, E and F at 8 points each. So our accounting could look like this:
A – 1
B – 2
C – 1
E – 8
F – 8

This would give the appropriate estimate for Week 2 but would miss credit for the full story value of A-C. On the other hand, if you keep the full story value of A-C, our plan for Week 2 would look like this:
A – 5
B – 5
C – 5
E – 8
F – 8

And then it looks like you are planning 31 points for a sprint that can only accommodate 20. It seems that somehow you need to keep track separately of how much work you estimate is really left on A-C to properly plan Week 2. So how do you properly account for partially complete stories across sprint boundaries? Is there some way you annotate that on the cards for partially completed stories?

First Level Answer

In this installment, I’ll try to answer the direct question that I was asked: “How do you properly account for partially complete stories across sprint boundaries?” Let’s start by defining some key terms: user story, story point, and velocity.

User Story
A user story is a business deliverable. When a user story is done, there is demonstrably more value present. A user story is something that some of our stakeholders would understand and be interested in.

Story Points
Not all user stories are the same size, in terms of the amount of work that will be required to deliver them. Story points are a relative scale that scrum teams use to estimate how much work each user story will require. A story that has an estimate of 2 story points is believed to be about twice as much work as a one-point story. Story points are estimates; they are not measurements. Since they are estimates, they are made before the work starts and are not adjusted after the work has been completed.

Velocity
Velocity measures the rate at which the team is delivering stories. That word ‘deliver’ is very important. The business wants to know when it will get the deliverables (user stories) from the team. Velocity is a metric that helps us predict that. If all stories were the same size, in terms of implementation effort, velocity would simply be the average number of stories the team delivers per sprint. Since stories are not all the same size, velocity is the average number of story points worth of stories that the team delivers each sprint. While estimates are guesses, velocity is a measured value. The unit of measurement just happens to be estimated story points.

Velocity is not a measure of how much work the team is doing. Velocity is not a measurement of how long it took to deliver the stories. Velocity is not a measure of how hard the team is working. And velocity is not a measure of the team’s productivity.

OK, we’ve defined some terms and concepts. Let’s get on to answering the question that was asked. If the team finished one story in sprint one, and its estimate was 5 points, then the team demonstrates that one story in their sprint review and records their velocity as 5 story points.

So the now the team moves on to planning sprint two. The question the team needs to answer is which stories do they have full confidence they will deliver by the end of this sprint. Story point estimates and velocity are tools that can help the team make better commitments about how many stories they will deliver. The team should consider more than just the points and velocity, however. They need to look at the specifics of each story the product owner is asking for and decide, as a team, if they have full confidence that they will be able to deliver that story this sprint. You say that the team believes they can complete stories A, B, C, E and F in sprint 2. That’s fine. If the whole team believes that they will deliver those five stories, then they may commit to them.

Let’s assume that the team manages to complete all five stories in sprint two. They have now completed 6 stories in two sprints. The total of all the story points estimated for those stories would be 5 + 5 + 5 + 5 + 8 + 8 = 36 story points. Thus, the team’s velocity is:
36 points / 2 sprints = 18 points per sprint.

If someone asked what the team’s velocity is, we’d say “18 points per sprint.”

This measured velocity can help the team plan for the future. For example, committing to deliver 20 points worth of stories in a sprint is probably too much for the team right now. The team’s velocity also helps the product owner with release planning. They can expect that, on average, the team will deliver 18 points per sprint and so they can forecast how many stories the team will be able to deliver over the next several sprints. After each sprint, the team will recalculate its velocity and the product owner can update the projections.

The tl;dr

In summary, count the story points for a user story in the sprint in which the story is delivered. Do not count partial points for partially completed stories. If the story was started in one sprint and finished in another, that’s fine. Velocity measures delivery, not work, so account for the delivery when it actually happens.

That’s concludes my first-level answer to this question. There is actually a lot more to explore. Stay tuned, as I plan to post a deeper analysis soon. Until then, happy scrumming!

Cheers,

Chris Sims

Posted in agile, scrum | 2 Comments

Dixit Sprint Retrospective Game

Dixit Game BoxI was inspired to create a retrospective game for agile teams, based on the game Dixit. Dixit is a game that makes use of picture cards. Each of these cards has an unusual drawing on it. The Agile Learning Labs team used it recently in one of our sprint retrospectives and it worked well. Give it a try with your team and leave a comment to let me know how it works for you.

Materials required:

A full set of Dixit picture cards is used. The rest of the supplies from the standard Dixit game are not used.
Each team member should have at stack of index cards, at least five.
Each team member will also need a pen.

Game Play

The team sits around a table. The deck of Dixit cards is shuffled and each team member is given six cards (this can be adjusted up or down as desired). The rest of the deck is placed in the center of the table face-down. Players will take turns being the leader. The tallest person (or shortest, or what-ever) is the first leader.

The leader looks through their six cards and chooses one that represents something that happened during the sprint. For example, let’s say that the team had to create a lot of documentation this sprint and so the leader selects this card from their hand.
Pile of books Dixit card

The leader places this card face-up in the center of the table.

Each player, including the leader, writes what they think the card represents on an index card, and then the index cards are placed face-down in front of each player. When each player has an index card in front of them, the player to the left of the leader turns their index card over and explains what they believe the Dixit card represents. That player leads a brief discussion of the event on their index card, and the discussion concludes by recording any potential action items for the team to consider.

The next player to the left then reveals their index card and the process repeats until it is the leader’s turn. The leader then reveals what they intended the card to represent. If the topic has already been identified by one or more team members, then each team member that correctly guessed the meaning of the picture gets a point and so does the leader. If no team member guessed the intended meaning of the Dixit card, then the leader facilitates a discussion about the topic and potential action items are recorded; no players receive points in this case. The leader then discards the Dixit card and draws a replacement from the top of the deck. Now the player to the left of the leader becomes the new leader and the process repeats. Continue for as many times around the team as feels productive.

Once the main game play is completed, the team considers the various action items that they have collected and selects one or two of these to schedule into the coming sprint as the outcome of the retrospective. Oh, and the player(s) with the most points win a fabulous prize.

Team playing Dixit retrospective game

Posted in agile, games, scrum, teams | 3 Comments

Quick Reference Guide for Splitting User Stories

foo


We’ve been talking a lot lately about splitting user stories.

After all, one of the keys to scrum team success and happiness is properly sized stories that play nicely in a sprint. To help teams remember the four easy steps to splitting a user story, we’ve developed a quick reference guide.

Download a copy for your scrum team today!

And if you missed all the juicy details on story splitting, here are quick links to all our recent user story splitting posts.

Happy splitting!
Laura

Posted in agile | Leave a comment

Splitting User Stories with Timeline Analysis

This is the last of five installments in my series on splitting large user stories into smaller user stories. If your scrum team isn’t able to complete a minimum of four user stories every week, then start with the first installment and work your way back to this one. The first 3 techniques I shared are my favorites, and I manage to split 95% of stories using those 3 techniques. Occasionally, I find a user story that I cannot split using conjunctions, generic words, or acceptance criteria. When this happens, I resort to timeline analysis.

With this technique, I ask my stakeholder to pretend that the user story is already done, and then I ask “What happens when the functionality gets used?” They will then describe a sequence of events. Even for things that happen non-deterministically, or which could happen in parallel, they still describe it sequentially; it’s just the way our brains and our language work. I then identify the verifiable steps in the timeline. For example, a user might describe this scenario:

I want to decide what to order at the restaurant. First I browse the menu. I like to look at pictures of the food, and read the descriptions. I’m concerned about calories, so I check the calories for the items I’m considering ordering, and then I check the prices. I also want the waiter to come and tell me about special items available that day. I really enjoy when the waiter describes the dishes in great detail, and even tells a story about why that item is the special of the day. The waiter will then go away for a bit so that I can consider my choice. When the waiter comes back, I’ll place my order.

From this timeline, we can identify several user stories.


As a diner at the restaurant,
I want a menu that lists each item with a description, price, calories and a picture,
so that I can decide which items I want to order

and

As a diner at the restaurant,
I want to be offered daily special items,
so that I can try unique dishes that aren’t usually on the menu.

and

As a diner,
I want some time to consider the daily special and the regular items before ordering,
so that I feel unrushed and happy about my final choice.


This technique works equally well for stories with a traditional user interface, or those that are very low-level and technical. Do be careful with this technique; it is easy to lose sight of the user and the value and then fall into technical decomposition instead of true story splitting. To combat this, write your new stories in the traditional format:

As a (type of user),
I want (something),
so that (some value is created).

If you can find your user and your value, then you are probably doing OK. This extra level of required care is why I use the timeline analysis as a last resort. The other techniques: conjunctions and connectors, generic words, and acceptance criteria all have the advantage of keeping you in the “As a, I want, so that” format automatically. You almost can’t go wrong.

Now that you are armed with these four tools for splitting user stories into smaller stories, you may be asking “When should I use them?” Split the stories at the top of your product backlog until they are small enough that the team can comfortably complete four to six of these stories each week. As you look farther and farther down the backlog, it’s OK for the stories to be larger and larger. What you want is a gradual transition from really large epic stories near the bottom of the product backlog to those nice little stories up at the top.

There is another good reason to split stories, which is to capture early value. Imagine that we have a user story for having wireless internet access everywhere in the resort. This might take a long time to implement and cost a lot of money. We could split out a story about having wireless access in just the lobby. This story will require less time, effort and cost to implement, yet it will deliver value to those users who need occasional access to internet while on vacation. Later, we can implement the rest of the wireless internet story.

OK, that wraps up this series on splitting user stories. Have comments or questions? Know a great technique that I didn’t present? Please leave a comment!

Here are quick links to all of the user story splitting posts.

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

Posted in agile | 1 Comment

Splitting User Stories with Acceptance Criteria

This is the fourth part of my series on splitting user stories. If you are just joining us, start with the first installment and work your way forward from there. Today’s technique is the third of four techniques to split user stories and it makes use of the user story’s acceptance criteria in order to split the story into smaller stories. What are acceptance criteria? Acceptance criteria are a list of pass/fail testable conditions that help us determine if the story is implemented as intended. Each user story should have between 4 and 12 acceptance criteria. The product owner works with the team to create, agree-upon, and record the acceptance criteria for each user story before the story enters a sprint.

Let’s look at an example. Here is a user story:


As a couple,
we want a romantic dinner for two,
so that we can have a date even more romantic than our first date

Here are some acceptance criteria for this story:

  • There are 2 lit candles and fresh flowers on every table
  • The main course offerings include steak, fish, and at least one vegetarian option
  • There are at least 2 kinds of red wine and 2 kinds of white wine available, as well as a Champagne
  • There is a string quartet or a piano player playing soft instrumental music
  • The waiters are wearing tuxedos

If we examine each one of the acceptance criteria, we can ask “Who wants this?” The answer to this question becomes the user in “As a (type of user).” Next, we ask “Why do they want that?” The answer to this question identifies the value in “so that (some value is created).” The body of the acceptance criteria provides the “I want (something)” part, and now we have all three parts for our new user story:


As a (type of user),
I want (something),
so that (some value is created).

Here are user stories that could be derived from the acceptance criteria above.

As a couple on a dinner date,
we want candles on the table,
so that the mood will be more romantic.

and

As a diner in the restaurant,
I want to be able to choose from steak, fish, and at least one vegetarian option,
so that I can order something that conforms to my dietary and flavor preferences.

and

As a wine lover
I want at least 2 kinds of red wine, 2 kinds of white wine and 2 Champagnes available,
so that I can choose a wine that will go well with my meal.

and

As a couple on a dinner date,
I want to hear instrumental music from a string quartet or a piano player,
so that the mood will be more romantic and I can still converse with my date.

and

As a couple on a romantic dinner date,
I want waiters that are wearing tuxedos,
so that we can feel like we are at a classy restaurant.

Using acceptance criteria to identify smaller sub-stories is very handy and powerful, because it is recursive. Every story needs acceptance criteria, and many acceptance criteria can become their own smaller stories. Of course, each of these new small stories needs to have acceptance criteria. And, we could use these acceptance criteria to break the stories down again. It’s turtles all the way down!

Tune in next week for the final installment in Splitting User Stories.

Here are quick links to all of the user story splitting posts.

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

Posted in agile | 2 Comments

Splitting User Stories with Generic Words

This is the third in my series on splitting larger user stories into smaller user stories. If you are just joining us, go back and read part one and part two. Don’t worry, I’ll wait right here for you.

Like the first story splitting technique – Conjunctions and Connectors technique – , the second technique -the Generic Words approach works by parsing the text of the user story. This time, instead of looking for connector words, we are looking for generic words. “What’s a generic word?” you ask. Any noun that isn’t a proper noun is generic, as are many verbs, adjectives, and adverbs. What we are looking for is a generic or general term in the story which could be replaced by several more specific terms to create a number of smaller stories. Perhaps an example would help explain this:


As a couple traveling with our family,
We want romantic activities to do together,
so that we can rekindle our love connection.

In this story, the word “activities” is pretty generic. We can replace “activities” with more specific words such as: couple’s massage, romantic dinner for two, and sunset couple’s cruise. We will get these stories.

As a couple,
we want to get a couple’s massage,
so that we can relax together and reconnect.

and

As a couple,
we want a romantic dinner for two,
so that we can have a date even more romantic than our first date

and

As a couple,
we want to go on a couples-only cruise at sunset,
so that we can enjoy romantic moments with no children around


With this technique you go from one general scenario to several more specific scenarios, each of which can be implemented separately. You will probably need some practice with this technique to get really good with it, so spend some time this week practicing! Come back in a week to learn the third technique for splitting user stories.

Here are quick links to all of the user story splitting posts.

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

Posted in agile | 2 Comments