Agile Learning Labs

Splitting User Stories with Timeline Analysis

Chris Sims — Wed, 01 May 2013 18:15:18 +0000

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.

The post Splitting User Stories with Timeline Analysis appeared first on Agile Learning Labs.

Splitting User Stories with Acceptance Criteria

Chris Sims — Wed, 24 Apr 2013 18:15:56 +0000

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

The post Splitting User Stories with Acceptance Criteria appeared first on Agile Learning Labs.

Splitting User Stories with Generic Words

Chris Sims — Wed, 17 Apr 2013 18:15:57 +0000

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

The post Splitting User Stories with Generic Words appeared first on Agile Learning Labs.

Splitting User Stories with Conjunctions and Connectors

Chris Sims — Wed, 10 Apr 2013 18:15:45 +0000

As I described last week, splitting large user stories into smaller user stories has many benefits for the scrum team and the business. We also agreed that before we try to split a user story that we want to write it in the traditional format:

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

So now that we have our big user stories massaged into this format, we are ready to try the first technique for splitting user stories: Conjunctions and Connectors. This is a dead-simple technique, and that’s why I always start with it. Simply read the story looking for connector words such as: and, or, if, when, but, then, as-well-as, etc.. Don’t forget that commas often function as connectors. When I see one of these connector words, I can usually split the story into two stories by separating the pieces that the connector words are holding together. Here’s an example:

As a couple planning a vacation for our family,
We want a resort that has activities appropriate for our teenage children,
as well as couples,
so that we can all enjoy our vacation.

Notice the middle line:
“We want a resort that has activities appropriate for our teenage children, as well as couples ”

We can break this into stories for the teenagers, as well as the couple.

As a teenager on vacation with my family,
I want activities to do with other teens,
so that I can meet other teens to hang out with
instead of being stuck with my lame parents the whole time.

and

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

Notice how the stories change as they get smaller. It is usually the case that when the story gets smaller, the value statement gets more specific. It’s also common for the user to be more specific, or sometimes change entirely. While it’s true that Mom wants her teenagers to have fun, we will probably be better off writing stories from the point of view of the teenager in order to satisfy this requirement. Sometimes other parts of the story get more specific as well. This is exactly what we want, as the smaller stories are not only easier to implement, but are described in more detail. This leads to a better understanding of the story, which leads to better estimates and, ultimately, an increased likelihood that the team will build the right thing.

OK, go practice this technique; your story splitting skills will grow the more you use them . Tune in next week when we explore the second story splitting technique.

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

Cheers,

Chris

The post Splitting User Stories with Conjunctions and Connectors appeared first on Agile Learning Labs.

Introduction to User Stories and Splitting Stories

Chris Sims — Wed, 03 Apr 2013 18:15:30 +0000

A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.

When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so that we can adjust the product plan, to better build the product that our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality that is being developed.

OK, smaller stories are better. How does a team take the big stories in its product backlog and split them into smaller stories?. I have 4 techniques that I use to split user stories, and I have yet to run across a user story that would not yield to at least one of these approaches. Someday I will find such a story, and hopefully I will learn a fifth technique.

Before applying these techniques, start by writing your story in the common user story form:

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

This isn’t the only way to write a good story, but any well-formed story can be written this way. The advantage is that writing the story in this format captures three important aspects of any good story:

1. Who is this functionality for?
This is described by the first line: As a (type of user). The more specific the user – the better the story.

2. What we should create?
This is described in second line: I want (something).

3. Why is it valuable to the user?
Yes, this is the third line of the story: So that (some value is created).

If we don’t know the “who, what, and why”- then we don’t really understand the story yet. If we don’t understand the story, then we probably can’t split it. Once we have the story in the traditional format, we are ready to begin splitting it. Tune in next week, when I’ll share the first, and easiest, of the four techniques I use to split user stories.

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

Cheers,

Chris

The post Introduction to User Stories and Splitting Stories appeared first on Agile Learning Labs.

Agile – From the Product Owner’s Perspective

Chris Sims — Fri, 01 Feb 2013 16:41:53 +0000

One of my fellow Certified Scrum Trainers, Henrik Kniberg, created this excellent video that describes agile software development from the point of view of the product owner. I’m really impressed, and I regularly share this with the participants in my Certified Scrum Master and Certified Scrum Product Owner workshops. Great job Henrik!

The post Agile – From the Product Owner’s Perspective appeared first on Agile Learning Labs.

Managing the Performance of Scrum Team Members

Chris Sims — Mon, 14 Jan 2013 08:00:52 +0000

A client recently contacted us for guidance regarding managing individual performance in a scrum environment. This is a growing company that successfully adopted scrum a few years back. They asked me what they should do with a scrum team member that is not performing. Should they implement a performance management system, and if so how? I’ve previously written about this from the other direction, what to do with your performance review system when the company adopts scrum.

The first question to consider is whether a performance management system is really called for at all. If the problem lies with one or two employees, I’d suggest dealing with that situation directly. Start with getting better at providing regular feedback. Feedback should be coming from the manager, the scrum master, and team mates. If the employee isn’t responding, then the manager needs to initiate a formal ‘fix it’ plan with the employee. This lets the employee know that their performance is unacceptable and spells out the changes needed in order to keep their job.

If you decide that a performance management system is appropriate, then you need to be clear about what kind of “performance” you want. If you are doing scrum, then what you want is high-performing scrum teams. Start with this as the goal, and shape a performance management system that will increase your chances of getting team-oriented behavior from your employees. If you build a performance management system that rewards heroes and rock stars, you will get people who spend their time focused on looking better than their teammates, instead of collaborating with them.

Sometimes it’s hard to see the things that contribute to a cohesive team. I once worked with a developer whose technical skills were merely acceptable. This company had a bit of an alpha-geek culture, and some managers thought we should let this developer go, since they “didn’t fit in” and “weren’t performing at the level of the others.” I resisted, having noticed that this developer was always willing to take the less-glamorous work that the rock stars hated doing. Additionally, this developer’s humble demeanor helped keep the peace among an otherwise high-strung group. In fact, this person was vital to the health and performance of the team. I resisted the pressure from above to let them go, and the team went on to greatness.

Of course, teams are made up of individuals and we want each one to be a strong as possible. For this reason, I suggest a performance management approach that focuses on helping individuals grow their skills. This can be done by building on strengths, shoring up weaknesses, or by expanding in to new skill areas so that they can contribute in new ways. To this end, each person should have a professional development plan that they co-create with their manager. This professional development plan will help them to identify areas of strength and weakness, and map out a path for growth. A regular stop along this path should be weekly one-on-one meetings with the manager.

What are your thoughts on managing the performance of scrum team members? Leave a comment and share!

Cheers,

Chris

The post Managing the Performance of Scrum Team Members appeared first on Agile Learning Labs.

Where does Quality Fit on a Scrum Team?

Chris Sims — Tue, 04 Dec 2012 10:15:33 +0000

A recent email:

Hi Chris. It was great to have you in Beijing and you provided us with awesome Certified Scrum Master and Certified Scrum Product Owner trainings. We are having internal discussions about the role of quality engineers in scrum. Should they be on the scrum teams? Do we need quality engineers if we are doing scrum? If we have them, who should manage them? Should we move them around from team to team?
Thanks,
J

My thoughts:

Have Quality Engineers on the Scrum Team

Scrum is based around cross-functional teams. This means that we want each team to have all of the skill areas necessary to take a deliverable from concept to delivery. For software products, this usually means we need people skilled in design, architecture, various types of coding, as well as testing. It is too much to expect every team member to be highly skilled in all areas; instead we have specialists on the team, each of whom has a core competency in one (or sometimes more) of the skills we need to get the work done. While these people are specialists, we also want them to be flexible enough to do work outside their area of specialty. Sometimes a C++ developer will write test automation. Sometimes a tester will do requirements analysis, and so on. We often call these people “generalizing specialists.”

So is quality engineering needed? For most of the scrum teams I’ve worked with the answer is yes, we need to have quality engineers on the scrum team. They bring special skills and a quality-centric view to the work. Are they the only ones who can do testing? No, when the team needs more testing than our QE specialists can do, other team members will help out. Is testing the only thing that our quality engineers will do? No, it is likely that the team will need them to make other kinds of contributions from time-to-time. Remember, that for every scrum team member, their main goal is the same: deliver the stories that the team committed to this sprint!

Who Should Manage the Quality Engineers on a Scrum Team?

So now that we’ve decided that we probably want quality engineers on the scrum team, who should they report to? It’s probably best that they report to someone who is, or was, a quality engineer. Think about what we want a manager to do. We want the manager to help the employee grow so that their contribution to the company continues to increase. We also want the manager to be the employees’ go-to person for all human resource issues such as: performance review, vacation approval, and career growth. Who better understands how to be a great quality engineer than someone who is themselves a great quality engineer? Another benefit of having the quality engineers managed by other quality engineers is that the manager becomes someone who can coordinate QE practices across scrum teams. There are many decisions to make regarding what tools we will use, and what practices we want to adopt across the organization. To best make these decisions, we want our QE people to regularly discuss these areas and make coordinated decisions. A manager is a logical person to make all of this happen.

The quality engineers across the organization will want to spend time with each other, so that they can coordinate the various ways that quality engineering work is being done. In these bigger gatherings of QE people, they can make decisions about what tools, techniques and practices to adopt and standardize on. They can learn from each-others’ experiences and evolve the way quality engineering is being practiced. So we want to have quality engineers on the scrum team, and we want them to have time to meet and work together outside of the team, in order to coordinate and improve how they work.

It can be very useful for individual skill and career growth, to have people report to managers who have the same skill set. Thus, quality engineers will be managed by quality engineers. Java developers will be managed by someone who knows Java development well, and so on. This sets up a bit of a matrix situation. The manager is responsible for helping their direct reports improve their skills and grow, as well as typical administrative task such as approving vacation requests. The team’s product owner, however, sets the business direction and decides the order of the stories that the team will be asked to deliver.

Avoid Frequently Moving Quality Engineers Between Teams

In general, we find that having stable teams, where same team members stay on the team for long periods of time, seems to work best. This may seem a little counter-intuitive at first. Traditional project management has included the practice of moving people with the right skills to what-ever project needed those skills at the moment. If we were machines, this would work great. But we are not machines. We are teams of human beings, and it takes significant time working together for a team to start to gel, and become high-performing. One popular model for how this happens is the Tuckman model which states that teams go through four distinct phases over time: forming, storming, norming, and finally, performing. It turns out that within some reasonable bounds, a team that has been together and made the journey to high-performing will produce more value than a team of experts who have just been pulled together. For this reason, we generally want to keep the same people together as a team for as long as we can.

What are your experiences and opinions on incorporating quality engineering in scrum? Leave a comment and share!

Cheers,

Chris

The post Where does Quality Fit on a Scrum Team? appeared first on Agile Learning Labs.

Where does User Experience Fit on a Scrum Team?

Chris Sims — Mon, 26 Nov 2012 09:00:55 +0000

A recent email:

My company is making a transition from waterfall to agile development using the guidelines from your book Elements of Scrum. In your coaching of various companies, I was wondering if you’ve worked with teams that have user experience designers (UX) and where they’ve fit into the process. As a manager, I wanted to get your thoughts on whether it makes more sense for individuals with these skills to be part of a scrum team as a team member or work with the product owner as a stakeholder.
Thanks,
K

My thoughts:

Thanks for your question on the role of user experience (UX) people on the scrum team. It comes up often, and so I thought I’d answer it publicly, here on our blog. The short answer is “It depends.” I’ve seen both approaches work: have the user experience people on the scrum team, or have the UX person be part of the product owner’s inner circle of advisors but not actually on the scrum team.

User Experience on the Scrum Team

If the UX people can do their work on each story effectively during the sprint, then it may work best to have them be part of the scrum team. In this case, the user stories tend to be focused on the business problem to be solved. The design, implementation, and testing of the solution happens during the sprint, including the UX work. In this approach, the bigger picture of the user experience emerges over time, in much the same way that a system’s architecture is evolved over time using emergent architecture techniques. There is certainly some thinking, design, and work that happens early, but the bulk of this work happens incrementally over time, with frequent refactorings of the user interface. For some products and teams, this is the best approach.

User Experience as Stakeholder

In other situations, the user experience people work closely with the product owner, and are not part of the scrum team. The usual pattern here is that the UX artifacts are part of the user stories. In this way, a user story will have an overview “As a (type of user), I want (something), so that (some value is created).” The story will also include acceptance criteria, and UX documentation such as wire frames or mockups. Of course, documentation is not sufficient to enable the team to truly understand the desired result, and so the UX person will have many conversations with the team members to help them understand what is desired, and to negotiate with the team regarding the inevitable trade-offs that will need to be made. Additionally, good UX people will take the working software that the team is creating and field test it with actual users to see if the user experience is working as desired.

Thus, the UX person is doing work ahead of the sprint, creating designs, wireframes, and mock-ups. The UX person is also working with the team during the sprint to ensure that the team is building software that embodies the desired user experience. And finally, the UX person is doing work after the sprint to validate the usability of the software that has been created.

Taking this model a step further, I have seen UX people who have become their team’s product owner. This can work really well, as a good UX person truly understands the users, what they are trying to accomplish, and what they value.

Cheers,

Chris

The post Where does User Experience Fit on a Scrum Team? appeared first on Agile Learning Labs.

Dymaxicon Leaves the Nest

Chris Sims — Thu, 15 Nov 2012 03:13:23 +0000

A couple of years ago, Hillary Louise Johnson and I had nearly finished writing The Elements of Scrum and we were discovering that the options for publishing it through traditional means didn’t satisfy us. A traditional publishing deal wouldn’t give us the creative control that we wanted, and the royalty terms offered by traditional publishers weren’t to our liking. The answer, Hillary saw, was to start a publishing company; Dymaxicon was born.

Hillary had big plans right from the start. “Because of my years spent as a journalist and author, I had a huge backlog of books I knew of that had never found a home with traditional publishers,” she says. “So I started making calls.”

The first book Dymaxicon published was a literary novel, The Bad Mother, by Hillary’s longtime colleague, Nancy Rommelmann. It garnered attention in the Huffington Post, The Oregonian, and the LA Weekly. By the time The Elements of Scrum came out, Hillary already had several other literary titles in the works, which have since been reviewed in major newspapers across the country and one was even excerpted in the New York Times.

In mid-2012, Hillary and I published Scrum: A Breathtakingly Brief and Agile Introduction, a kind of Cliff-Notes version of The Elements of Scrum, designed to meet the needs of executives and others who wanted or needed a quick-start guide. Within months, both books had come to consistently rank #1 and #2 on Amazon’s bestseller lists for software project management.

In 2012, Hillary also collaborated with our fellow agilist Tobias Mayer to bring out a new kind of literary journal, 113 Crickets, which mixed writing from technology mavens and literary figures, some known, like the Stanford poet Kenneth Fields and the actor James Franco, and others who were seeing their work in print for the first time. Meanwhile, the agile community turned out to support the fledgling literary magazine through advertising.

By using a lean business model and developing projects iteratively, Dymaxicon was able to bootstrap its way to profitability. And today, Agile Learning Labs’ child Dymaxicon is striking out on its own. What started as a better way to publish The Elements of Scrum has become Hillary’s full-time passion, and so she is leaving Agile Learning Labs to focus on her role as CEO of the newly independent Dymaxicon LLC. All of us at Agile Learning Labs wish Hillary well and look forward to cheering Dymaxicon onto even greater successes in the future.

The post Dymaxicon Leaves the Nest appeared first on Agile Learning Labs.