Learn agile and Scrum tips and techniques from expert ScrumMaster, educator and author Mike Cohn of Mountain Goat Software.Mike Cohn provides certified scrummaster training and agile training in order to build extremely high performance development organizations.
Saying no can be very difficult. Most of us like to please others. But when we say no, we disappoint the requester.
But saying no to stakeholders is an important part of the product owner’s job. The product owner is tasked with optimizing the value delivered by a product, not with saying yes to every customer request.
For every time a product owner says yes to some stakeholder’s feature request, the product owner will need to say no to some future customer request. The team’s time is limited and a yes today will necessitate saying no to some later opportunity.
This means that learning to say no to stakeholders is a skill every product owner needs to master. I want to share six guidelines for how you can do so politely but firmly.
1. Be Clear with Stakeholders: Is this No? Or No, for Now?
When product owners need to tell stakeholders that they are not prioritizing a particular feature request, they should be clear about what their “no” means.
If you are you saying that you’ll never have the team work on this feature, don’t leave the door open to encourage the stakeholder to ask again later. That’s a waste of their time and frustrating for you to have to continually say no when you know you’ll never do that feature.
If on the other hand you’re telling the customer no for now--that later you might work on that feature--be clear about that as well. You might, for example, say,
I'm sorry we can’t work on that right now. Believe me, I wish we could. But we’ve already made commitments to deliver [name whatever it is] by August. I need to keep the team focused on that or we risk missing that commitment. But if you remind me about this in August, I promise to consider doing it after that.
Notice in this example reply, I didn’t suggest promising you’d do it later, only that you’d consider it.
Also, notice that you put the burden back on the stakeholder or customer. Make them re-initiate the request or remind you when the time is right. I do this to make sure the feature is still important to them. If the stakeholder isn’t willing to do something as minor as remind you about a feature request, I’d question whether the feature was ever very important or urgent.
Most importantly, don’t let the stakeholder walk away thinking they should ask again in a month if your answer was really that you never intend.
2. Express Appreciation and Empathy for Customers
When presented with a feature request, product owners should always thank the stakeholder and indicate their understanding of why the feature is important to that stakeholder.
Someone took time to ask something of your team. That means they’re interested in your product. Tell the customer that you appreciate their taking the time to ask. Something like this is all you need to say:
Thank you. I appreciate you thinking of how our product could be made better.
Beyond being appreciative, product owners should also show empathy for the stakeholder’s situation. You’re about to say no to a request that is likely very important to them. The feature may, in the stakeholder’s mind at least, be required to fulfill goals assigned by their boss, and might even affect them financially.
Before conveying your empathy, be sure you understand why the feature is important to the customer. And if you don’t understand, make sure you do before saying no to the feature request.
You can express your empathy for their situation with a statement like,
I can see why this feature is important to you in achieving [whatever it is].
Be sure you’re sincere about this. I don’t think I’m unique in being frustrated by false empathy.
3. Offer Only One Reason for Saying No
When saying no, it’s best for product owners to provide one compelling reason rather than a list of reasons. When offered a list of reasons, people tend to pick the weakest reason and argue against it.
Imagine I am your customer and I ask you to have your team put aside their current work in favor of a feature I want. You tell me,
I’m sorry but I can’t do that. We’ve already planned this sprint. I’d need the team to have another planning meeting, and they won’t like that. And I’m confident that what we’re currently working on is higher priority.
What part of your argument do you think I’ll attack? The need to do another planning meeting or that the current work is higher priority?
I’ll go after the argument that the team would need to do another planning meeting and won’t like it. I might offer to make the meeting less unpleasant by doing it over lunch and I’ll buy the pizza.
Even if you still don’t like my plan, I’ve now changed the conversation: We’re arguing about whether to conduct a meeting rather than over the merits of the feature. That’s a more difficult argument to win.
And it’s the wrong basis for making the decision.
Be firm and offer your one most compelling reason for saying no. If the stakeholder successfully convinces you to change your mind by arguing that point, it may well be worth considering whether your secondary reasons for saying no are sufficient. If not, you might need to say yes to the feature.
4. Convey that You Each Have the Same Goal
If the product owner and the requesting stakeholder share the same overarching goal, the product owner should mention it when delivering unwelcome news.
A product owner and stakeholders each often have many different goals. And, yes, sometimes, they are in conflict. But usually there is a higher, product-level goal that is shared and that you can reference.
This is particularly easy if you are both part of the same company. In that case, say something like,
As much as I’d love to have the team work on that for you, we need to stay focused on [larger, shared goal].
As I’m sure you remember, we’ve all been given the goal to [larger, shared goal].
Reminding the customer that you share a common goal helps them understand why you need to say no, even if they still don’t agree fully with the answer.
5. Explain the Consequences of Saying Yes to the Stakeholder
When rejecting a stakeholder request, product owners should explain the consequences of saying yes.
This can help the stakeholder see why you feel compelled to say no. You could, for example, say,
If we worked on your feature instead, we won’t be able to meet the big deadline.
The team is already working long hours. I can’t add this to their workload without removing something else that we’ve already committed to someone else.
Explaining the consequences will help the stakeholder understand, and hopefully empathize with, why you are saying no.
6. Offer the Customer an Alternative
Instead of outright saying no to a customer, a product owner may be able to offer an alternative.
You might offer something like:
We can’t possibly do everything you’ve asked, but what if we did this subset of it?
I can’t have the team work on this right now, but what if we start on it in three weeks?
Be careful: Only offer an alternative if you really mean it.
Saying No Doesn’t Need to be Difficult
Product owners often fear saying no and disappointing the stakeholder or customer. But saying no doesn’t have to be so difficult.
I’ve found that being clear, providing one reason rather than many, being empathetic and appreciative, conveying that we share the same ultimate goal, explaining the consequences of saying yes, and offering an alternative make saying no much easier.
When done well, saying no can improve, rather than harm, a product owner’s relationship with the stakeholder.
What Do You Think?
How do you tell stakeholders no? Have you found certain techniques helpful or harmful? Please share your thoughts in the comments below.
The ability for a team to self-organize around the goals it has been given is fundamental to all agile methodologies, including Scrum. In fact, the Agile Manifesto includes self-organizing teams as a key principle, saying that “the best architectures, requirements, and designs emerge from self-organizing teams.”
As part of deciding how best to achieve the goal given them, some teams will decide that all key technical decisions will be made by one person on the team.
Other teams will decide to split the responsibility for technical decisions along technical boundaries: Our database expert makes database decisions, and our most experienced Python programmer makes Python decisions.
Still other teams may decide that whoever is working on the feature makes the decision but has the responsibility of sharing the results of the decision with the team.
Not Every Agile Team Will Self-Organize in the Same Way
There are two key points here:
First, not every agile team will choose to organize themselves the same way, and that’s OK.
Second, making use of the collective wisdom of the team will generally lead to a better way of organizing around the work than will relying solely on the wisdom of one personnel manager.
The benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for its work that a manager may have missed. Rather, it is that by allowing the team to self-organize, it is encouraged to fully own the problem of performing its work.
Can We Really Expect Agile Teams to Self Organize?
A common criticism of self-organizing teams is, “We cannot just put eight random individuals together, tell them to self-organize, and expect anything good to result.”
Well, I don’t know if we can put eight random people together and expect anything either, but an agile team should not be a random collection of people. In fact, those in the organization responsible for initiating a Scrum project should expend a lot of effort in selecting the individuals who will comprise the team.
Management Exerts Subtle Control over Self Organization
In the original paper describing Scrum, Takeuchi and Nonaka identified “subtle control” as one of its six principles. They list staffing decisions as a key management responsibility.
Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary [is a key management responsibility]. “We would add an older and more conservative member to the team should the balance shift too much toward radicalism,” said a Honda executive. “We carefully pick the project members after long deliberation. We analyze the different personalities to see if they would get along.
Getting the Right People on the Agile Team
If you are a personnel manager or otherwise influence team composition in your organization, here are some of the factors to consider.
Include all Needed Disciplines on Agile Teams
As a cross-functional team, it is important that all skills necessary to go from idea to implemented feature be represented on the team. Initially this may mean that team size is slightly larger than desired.
But, over time, individuals on a Scrum team will learn some of the skills possessed by their coworkers. This is a natural result of being on a Scrum team. As some team members develop broader skills, other individuals can be moved onto other teams.
Mix of Technical Skill Levels on Agile Teams
Subject to considerations of team size, you should strive to balance skill levels on the team. If a team has three senior programmers and no less-experienced programmers, the senior programmers will need to code some low-criticality features that they could find boring.
Not only might a junior programmer have found such features enjoyable to work on, that programmer would also benefit from learning through association with the senior programmers.
Balance Domain Knowledge on Agile Teams
Just as we strive to balance technical skills, we should strive for a balance between those with deep knowledge of the domain in which we are working or the problem we are attempting to solve.
This is not to say that if we have the opportunity to assemble a team entirely of domain experts we shouldn’t take it. Rather, we should consider the long-term goals of our organization.
One of those goals is likely the build up of domain knowledge throughout the organization. You’ll have a hard time achieving that if you put all of the domain experts on one team.
Seek Diversity on Agile Teams
Diversity can mean many different things—gender, race, and culture being just three among them. Perhaps equally important can be how individuals think about problems, how they make decisions, how much information they need before making a decision, and so on.
It takes time for agile team members to learn to work well together. Strive, therefore, to keep team members together who have worked well together in the past. When forming a new team, consider how long members will be able to work together before some or all are dispersed to other commitments.
Some Common Objections to Self-Organizing Teams
Let’s consider some common objections to relying on a team to self organize.
One Dominating Person Will Make All Decisions
A common concern is that one dominating personality, such as a tech lead, will decide that self-organization means he or she gets to make all decisions.
Or one dominating personality will force his or her will on the team before the team even has a chance to discuss an issue.
If you notice this starting to occur, take the dominating personality aside and inform her of the issue. Let her know that even in situations where she may know the “right” thing to do, she should sometimes refrain from voicing her opinion before others have a chance to express their thoughts.
Ask her if she thinks the team would make the right decision if she were to present her thoughts as an opinion rather than as an unchallengeable decision.
Enlist her assistance as a mentor to the others—her job should be not just making sure the right decisions are made but that team members grow such that they will make the right decisions on their next projects, where she may not be there for them.
My Team Expects the Scrum Master to Lead
A second common objection is that the team is too passive to self organize and will instead look to its Scrum Master or coach to lead and make important decisions for them.
If this happens, make sure team members know that the Scrum Master’s job is to support them, not to make decisions for them. If you are in a role as a combined Scrum Master / team member, you do not need to suppress your opinions and keep quiet all the time.
However, you should look for ways to engage others by not making the decision in all cases. For example, try asking questions of others before giving your opinion.
The Team Is too Junior to Self Organize
A third concern is that team members are too junior to self organize.
I have never met a team too junior to self organize. If team members have enough experience to build a software product, they probably have enough experience to figure out how to organize themselves.
If not, provide the team with training or coaching.
Often, this objection really masks the objection of, “I don’t trust the team to self-organize in the way I want them to.” Too bad. Exert subtle control over the team in who you put together to form the team and the goal you give that team, not in how it self organizes to do its day-to-day work.
What’s Your Experience?
Has your team embraced the idea of self organizing around their work? If not, what problems have you experienced? How have you overcome them? Please share your thoughts in the comments below.
I hope so. (Well, unless you’re a product owner or in some other role!) I’ve spent over 20 years as a Scrum Master. Over that time, I’ve given and collected quite a lot of advice. I’ve distilled it down to the ten best bits for you.
1. Never Commit the Team to Anything Without Consulting Them First
As the Scrum Master, you do not have the authority to accept change requests (no matter how small) on behalf of the team. Even if you are absolutely positive that the team can fulfill a request, say, “I need to run this by the team before we can say yes.”
And certainly don’t commit the team to deadlines, deliverables, or anything else without first talking to team members. You may not need to talk to the whole team--plenty of teams will allow some or all members to say, “Yeah, we can do that” without a whole-team meeting. But it’s still their decision, not yours.
2. Remember You’re There to Help The Team Look Good
Being a Scrum Master is not about making yourself look good. You look good when the team looks good. And they look good when they do great work.
You know you’re doing your job well when those outside the team start to wonder if you were even needed. Yes, it can be scary if your boss wonders if you’re necessary. But a good boss will know that your skill and expertise make you appear unnecessary when in fact you are indispensable.
Trust your manager to understand the difference between looking unneeded and being unneeded.
3. Don't Beat the Team over the Head with an Agile Rule Book
Neither Scrum nor agile comes with a rule book (though some have attempted to create one).
If your product has users, consider writing user stories. But stories aren’t required to be agile. If someone needs to know when you’ll deliver: estimate. If not, maybe you don’t. If you think an end-of-sprint review is too late to receive feedback, do one-at-a-time reviews as each feature is built.
Being agile is about honoring the principles and values that create agility. If you stay true to those, you can’t go too far astray, regardless of what some may tell you.
4. Nothing Is Permanent So Experiment with Your Process
Part of honoring the principles of agility is to experiment with your process. Encourage the team to try new things.
Does your team love two-week sprints and think they’re working perfectly? Great. Now ask them to try a one-week or a three-week sprint and observe the results. Experiments might not always be popular, but they are the best way to ensure that you continue to uncover new, better ways of working.
5. Ensure Team Members and Stakeholders View Each Other as Peers
Team members and business-side stakeholders each bring an important perspective to a product development initiative. As such, each needs to be valued equally.
When either side views the other as something to be tolerated, the organization as a whole suffers. Development teams need to understand the unique perspective brought by stakeholders. And stakeholders need to respect the development team, including listening when developers say that a deadline is impossible.
6. Protect the Team, Including in More Ways than You May Think
Perhaps the most often given agile advice is that a Scrum Master needs to protect the team from an overly demanding product owner or stakeholders. And that’s good advice. Sometimes product owners simply ask for too much too often and too aggressively. This forces teams into cutting corners, usually quality corners, that come back to haunt the project.
And so a good Scrum Master protects the team against this.
But what you don’t hear as often is that a good Scrum Master should also protect the team against complacency. Good agile teams seek constantly to improve. Other teams settle, perhaps unconsciously, into thinking they’ve improved enough. And they likely are dramatically faster and better than before they’d heard of agile. But even great teams can often become even so much better.
Great Scrum Masters protect teams from ever feeling they’ve got nothing left to learn.
7. Banish Failure from Your Vocabulary
Every now and then I’ll visit a team that refers to a sprint as a “failed sprint.” Usually this means the team didn’t deliver everything they planned. I hardly consider that a failure, especially if the team finished most planned items or if they deftly handled an emergency.
When a basketball player shoots the ball toward the basket and scores, it’s called a field goal. When the player misses, it’s called a field goal attempt. Not a failure. An attempt.
Good Scrum Masters help teams adjust their thinking so that they recognize sprints and features that fall short of expectations as attempts rather than failures.
8. Praise Often But Always Sincerely
The other day I told my teenage daughter that I was proud of her. Her face lit up. That shouldn’t have surprised me. Who wouldn’t like to be told someone is proud of them?
But the way she reacted made me realize I must not tell her this often enough. I thought it was equivalent to me telling her something obvious, such as, “You’re tall.” But I learned it wasn’t.
Don’t ever offer false praise. No one wants to hear that. But when your team members do good work, let them know. Chances are, they aren’t hearing it often enough.
9. Encourage the Team to Take Over Your Job
A team that is new to agile will rely on their Scrum Master or coach in significant ways. The team may not know how to keep daily scrum meetings under fifteen minutes. Or they may not understand the importance of overlapping work or of being a cross-functional team.
The same is true of a an inexperienced sports team. The coach of the little kids learning to play football (soccer) needs to teach them everything. When my daughters were 6, their coach would run along the sideline the entire game yelling, “Kick and run!” If he didn’t, the young players would forget. Even with him yelling, occasionally some kid would just sit down on the grass and stare.
Contrast the coach of the young kids with the coach of a World Cup team. On a World Cup team, players have learned what to do. If the coach is late for practice, the players will know what drills or exercises to start the day with. The World Cup coach doesn’t need to remind the players to kick and run. But the World Cup team would never tell you they don’t need a coach at all.
No matter how good an agile team gets, I still think they benefit from having a Scrum Master or coach. But good agile teams take on some of the more straightforward coaching tasks themselves as part of their own journeys to mastering the skills needed in product development.
10. Shut Up and Listen
Some of the best coaching or mentoring you’ll do is to stay silent and let the team figure out the answer.
This can be hard. When you see your team struggling to figure out what to do, it’s natural to want to jump in and offer advice. But if you solve problems or even offer suggestions too readily, team members learn to just wait for you to solve every problem for them.
I don’t want to imply you can’t ever offer suggestions. You’re a smart person. If not, you wouldn’t be in the role you’re in. But part of being a great Scrum Master is helping teams learn how to solve problems on their own. If you solve every problem team members face, they don’t get a chance to learn how themselves.
What’s Missing from this List?
I’m sure I’m missing some pearls of wisdom. What is some of the best one-sentence advice you’ve received or given as a Scrum Master? Please share your thoughts in the comments below.
Your agile team runs a series of sprints, always doing the highest priority work as chosen by your product owner. But after that series of sprints, you look back at what the team accomplished. And it’s not very satisfying. All the team seemed to do was move from emergency to emergency, putting out one fire after another.
The team very likely got a lot of work done. But it doesn’t add up to much.
What happened? You fell into the trap of prioritizing based on what seemed most urgent at the start of each sprint, a frequent side effect of the iterative and incremental nature of agile. There’s a better way.
The Agile Prioritization Trap: Selecting Work Each Iteration
Selecting whatever work seems most important at the start of each iteration can be sub-optimizing in some cases. It can lead product owners to prioritize work on the crisis du jour, whether that’s
A hot tech support issue
Something that cost a sale yesterday
The latest whim of an important stakeholder
While any of these may be the most important thing to work on, all too often they are not strategic. And by choosing to work on whatever someone is screaming about in the moment, the product owner forgoes the opportunity to make progress on something bigger, more important or more strategic.
Prioritizing Without Goals Is Like Scaling Mountains without Maps
My fellow residents of Colorado and I are proud of our 53 “Fourteeners,” which are mountain peaks that are at least 14,000 feet high (4,267 meters). There are two ways to summit a Fourteener.
In the first approach, you simply drive to the base of the mountain and start hiking toward the highest thing you see. That will almost certainly be a false peak, which only appears to be the summit because it obscures the real summit.
But, having climbed the false peak, you can now see a higher peak. Believing it to be the true summit, you climb it. And discover that it, too, is a false peak.
You proceed this way until you finally do see the true summit. But between you and the summit is a deep valley. And to reach the 14,000-foot summit, you have to first descend 10,000 feet before climbing back up.
Clearly, this is not a good way to summit one of Colorado’s Fourteeners.
The second approach involves buying a topographic map at a local hiking store. Equipped with the map, you can then plan a more efficient route up the mountain that avoids the need to descend and re-ascend 10,000 feet.
Multi-Iteration Goals: The Product Owner’s Map
For the agile product owner, the equivalent of the topographic map is having a larger, multi-iteration goal. Without a multi-iteration goal, the product owner is merely climbing from false peak to false peak. That product owner and team may eventually arrive at their ultimate destination, but often only after descending and climbing out of the equivalent of the 10,000-foot valley.
It’s so tempting, though, to address those short-term crises instead.
First, it gives the product owner a sense of accomplishment: Something has been completed and can be ticked off the to-do list. Second, it appeases whoever is asking for the immediate solution. Most of us like to please other people, and this does that, often with only an invisible or unacknowledged impact on the bigger, longer-term, and usually more important goal.
When Prioritizing, Remember What Is Urgent Is Seldom Important
United States President Eisenhower knew how critical it is to distinguish between important matters and urgent ones. Although history is unclear on whether Eisenhower actually phrased it this way, he is often quoted as saying,
“What is important is seldom urgent, and what is urgent is seldom important.”
However he phrased it, Eisenhower was saying that those urgent crises we all get tempted to work on are not usually important in terms of achieving our overarching goal.
A good product owner will be careful to consider both the importance and the urgency of product backlog items when prioritizing work for the team.
Product Owners Should Identify a Significant Objective Quarterly
But if a product owner doesn’t know what it’s important, the urgent will always win. And this leads to the unsatisfying series of sprints I described at the start of this post. When an agile team goes from urgent issue to urgent issue, the immediate gratification fades as the team and the stakeholders realize no progress was made toward more important goals.
This means it’s vital for a product owner to define an important significant objective. I find that the best significant objectives will take the team about three months to accomplish.
Taking more than a single iteration is important because it focuses the team on a longer time horizon. This means the significant objective should be an important business result, such as migrating a portion of a system to a new technology; adding a big, important and noticeable feature; or any number of things.
But it needs to be significant. For a new product, it could be creating a minimum viable product (MVP). For an existing product, it might be adding a minimum marketable feature (MMF). Some organizations will refer to it as a wildly important goal (WIG).
Equipped with a significant objective—whether in the form of an MVP, MMF, or WIG—the product owner will be better able to assess urgent needs. If addressing an urgent issue is more important than working toward the significant objective, by all means the team should be directed toward the urgent issue.
The intent of establishing a significant objective is not create a slavish devotion to a multi-iteration goal. Rather, it is to establish a mechanism to support the product owner’s prioritization decisions.
Without a significant objective against which the importance of urgent issues can be compared, the urgent will always win.
What’s Your Experience?
Have you experienced the unsatisfying result of a series of sprints that focused only on urgent issues? How does your product owner or team guard against favoring the urgent over important, longer-term goals? Please share your thoughts in the comments below.
In their role as facilitators, Scrum Masters, agile coaches, product owners, and others often need to help teams achieve consensus. This could be a product owner getting a group of stakeholders to agree on a significant objective for the coming period. Or it could be a Scrum Master wrapping up a retrospective and seeking agreement on which improvements team members to want to pursue.
I want to share four consensus-building techniques for these and similar situations. You’re probably familiar with a couple of them but perhaps not with all. After describing each technique, I’ll offer some guidance on choosing between them.
Consensus-Building Approach 1: Dot Voting
Dot voting is a useful approach when a group wants to select multiple options from a larger list. I’ve used dot voting lately in the following situations:
As part of a team choosing what to improve at the end of a retrospective
With my family to choose a subset of fun things to do on an upcoming vacation
As part of an executive team to determine the organization’s top priorities for the coming quarter
Dot Voting in Practice
In dot voting, each person is given some number of votes. Usually each person is given more than one vote but fewer than the total number of options being considered. Dot voting also works if each person is given only one vote, but at that point is nothing more than simply having each person vote for one favorite by a show of hands.
All participants are usually given the same number of votes. This is certainly the most equitable. You could certainly use dot voting and give one person more votes, but I’ve never done that and it’s likely to feel very unfair to others.
After a list of possible options has been generated (usually through brainstorming), each person places their dots next to the item or items they favor. This can be done with colored markers or by buying little sticky dots from an office supply store.
In most uses of dot voting, you’ll want to allow people to place multiple dots next to a highly favored option. For example, in my family’s vacation planning, I really wanted to spend one day on a sailboat. I voted all five of my dots on that. My wife gave it one vote and put her other four dots on two other items.
Waiting to See How Others Vote
In dot voting, some people may hesitate a bit to vote because they want to see how others vote. Perhaps my wife wanted to go sailing as much as I did. But after she saw my five dots on that option, she put four of her dots elsewhere, feeling confident that six total sailing votes would be enough.
In general, don’t worry about this. For every person who stalls to see how the early votes shape up, there will be others who vote instantly, hoping that will influence others.
Alternatively, if you are concerned, have individuals vote privately on paper and then hand you the votes to be tallied.
Choosing the Winners
Because dot voting is most commonly used when a group wants to select multiple options, achieving consensus means identifying a set of winning options. There’s no standard way of doing this.
Before voting, you might say, “We’re going to pick the three [or whatever] top vote-getters.” This works well when you know you need a subset of a certain size. Or you can wait to choose your subset size after voting, which is often better because there’s usually a big drop off in votes between winning and losing options.
When to Use Dot Voting
Dot voting is an excellent approach when multiple courses of action can be chosen. It is also good for revealing overall breadth of consensus. For example, if two items win with three votes but eight other options each have one vote, that indicates a fairly weak consensus. This could be a sign that more discussion is needed, either in that meeting or on an ongoing basis afterwards.
Consensus-Building Approach 2: Roman Voting
Roman voting takes its name from practice of a Roman emperor holding a thumb up or down to indicate whether a gladiator would live or die.
Roman voting is used by teams or other groups in agile organizations when making a single yes/no decision. After discussing the merits of a possible decision, each participant votes. A thumb up is a vote in favor of a decision. A thumb down is a vote against that decision.
Suppose a team wants to go for a group lunch. Someone says, “Let’s go to the burger place next door.” A vote is called for and results in three thumbs up, two down, and one sideways.
Be Careful of the Sideways Thumb
You want to be careful of sideways thumbs. In the restaurant example, this probably means someone doesn’t care: I could eat there or not, but I don’t have a strong preference.
That’s fair in this example. But it’s not in others.
For example, suppose the team is meeting to make a decision about whether to hire a new team member everyone just interviewed. And Caleb holds his thumb sideways.
What does that mean? We can’t half hire the person. A decision like this is binary. We either hire or we don’t.
I share this example because it used to happen to me a lot. A team member would hold a thumb sideways and say something like, “The candidate is good, but we might be able to find a better DBA.”
Uh, sure, I’d think. We never set out to hire the world’s best DBA. We just wanted a great DBA who would also be a fit for this team. What I really need to know is whether this candidate is that person or not.
When to Use Roman Voting
Roman voting is best used when a group needs to choose one option. For example, should we use a particular architecture or technology, should we hire this person, or should we change to three-week sprints.
Consensus-Building Approach 3: Fists of Five
I was first introduced to the fists of five approach to assessing consensus by Jean Tabaka, author of Collaboration Explained This approach is helpful when a facilitator wants to allow and gauge a range of agreement. For example, I might love the idea of going to the hamburger restaurant next door, you might be ok with it, and another team member might hate that place. Fists of Five is more nuanced than approaches like Roman voting.
What the Fingers Mean
In a fists-of-five vote, each team member will hold up the number of fingers that indicates how strongly he or she supports a decision. Various meanings can be given to the different number of fingers, but here’s my favorite:
Five fingers: This is a great idea. I wish I’d thought of it.
Four fingers: This is a good idea and has my full support.
Three fingers: I’m neutral. The idea is OK. Maybe there’s a better idea. Maybe not.
Two fingers: I don’t like this idea. I’d prefer we do something different.
One finger: This is a project-threatening decision. We need to pursue an alternative.
Before You Start, Agree on a Level of Agreement
Before even holding a first fist-of-five vote, team members should discuss and agree on how strong their consensus needs to be. For example, an architectural decision would likely warrant greater consensus than which restaurant should cater Friday’s planning meeting.
Let’s look at a couple of sample degrees of consensus.
A team might be tempted to say that all decisions require everyone to hold up at least three fingers. This is a very strong form of consensus. This means no one thinks the idea is even a slightly bad one. I’m not saying you shouldn’t pursue this level of agreement in some cases, but it’s a very strong level of consensus, meaning it will likely take longer to achieve.
Consider instead a team that agrees a decision is good enough as there are more four- and five-finger votes than one- and two-finger votes. This is a much more moderate degree of consensus and would be easier to achieve. But, there might be some significant second-guessing if the decision doesn’t produce perfect results.
Finally, consider a team that decides it will move forward with any decision that doesn’t have any one-finger votes. Blocking a decision with a single one-finger vote is essentially granting veto power to each person.
As with the other examples I’ve given, there may be times when this is appropriate. For example, allowing veto power may be good for deciding where to go for the team lunch on Friday. Everyone but Mary wants to eat at The Hungry Heifer steak restaurant. But Mary holds up one finger because she’s vegetarian and the Hungry Heifer only serves beef.
Mary’s one-finger doesn’t really indicate that this is a project-threatening decision per my definitions above. But a team choosing to eat somewhere one team member absolutely cannot eat is rude and generally a bad decision.
Remember, you can use different degrees of consensus for different decisions. But before voting on a particular issue, have a short discussion over what consensus means for the decision about to be made.
Showing the Fingers
Once participants have agreed on the degree of consensus being pursued, participants discuss the issue, and vote when ready. Normally on a count of three, each participant holds up one to five fingers. (If one finger, be sure it’s not the wrong finger!)
Assess the results and if consensus is achieved, you’re done. If not, participants discuss and vote again. Participants can agree to lower the degree of consensus being sought if necessary.
When to Use Fists of Five
Fists of Five is good for both gauging a degree of consensus and voting to make a decision. Like Roman voting, it should be used when selecting one option among many rather than when choosing multiple options.
Consensus Building Approach 4: 1-2-4-All
The 1-2-4-All approach is more of a technique for building consensus than for voting. In fact, this approach may frequently end with a vote using one of the other three techniques.
The approach draws its name from the number of people involved in each of a series of conversations. It starts with each person spending a few minutes (2-5 is usually quite sufficient) making up their own mind about a decision.
Pairing the Pairs and Beyond
Individuals then pair up. Each shares their own opinion and the pairs try to gain agreement. How pairs are formed is completely up to you. You could form specific pairs by assignment or simply by whoever is adjacent to one another in a meeting.
If an odd number of people are present, the facilitator can sit the discussion out, especially if a truly impartial facilitator. Alternatively the facilitator can be part of a pair but act more in a listener-only mode to help the other person prepare arguments in favor of a position.
Pairs are normally given 5-10 minutes for their discussion. Although this can vary based on the criticality of the decision being made, I don’t recommend going much beyond 15 minutes.
After all pairs agree or the agreed upon time limit has been reached, pairs of pairs are formed. This is the “4” of the approach’s name. It’s quite possible you’ll have groups of different size at this point. That’s fine, adjust group sizes as seems best. These group are given 10 to 15 minutes to try to gain consensus among themselves.
After all groups have reached consensus or after the timebox expires, the groups of four are merged. For a typical agile team, this will usually be the whole team. If not, allow progressively larger groups to talk until the whole team is in one group.
With the whole group together, encourage the full group to come to agreement. It doesn’t always happen, but the 1-2-4 discussions often help make the full-group discussion easier. If appropriate, use dot voting, Roman voting, or fists of five to make the final decision.
When to use 1-2-4-All
The 1-2-4-All approach is best used on important decisions and when a team is nowhere near consensus. The increasingly large discussion groups ensure each person has a chance to be heard but also includes time at the start for individual thought.
Choosing an Approach to Gaining Consensus
Each of the approaches I’ve described has its own strengths and weaknesses. A good agile facilitator will use each at different times. No single approach is right for all decisions and all teams.
If you want to select multiple options from a larger set of options: Use dot voting.
If making a decision is important but it’s more important that everyone deeply understand and buy into a decision, use the 1-2-4-All approach possibly followed by one of the three voting approaches.
If you want to select a single option and a simple yes/no decision is good enough, use Roman Voting.
If you want to select a single option and need a more nuanced consensus, use fists of five.
To help choose the right approach, you may want to use the following diagram, which generalizes a decision-making process. Always use your own judgment based on the criticality of the issue, significance of disagreement, and more.
Agile teams should choose the consensus-building approach that best fits the decision at hand.
How Do You Gain Consensus?
Even high-performing agile teams struggle to build consensus at times. These 4 techniques help leaders achieve and assess agreement among team members.
When do you use these approaches? What other approaches have you found helpful for gaining or measuring consensus? Please share your thoughts in the comments below.
Long before the world discovered agile, prioritizing bug fixes was a challenge in software development. But agile’s short iterations make it even harder for many teams to decide which bugs to fix and which to put off. The good news is, an agile team typically has far fewer bug fixes to sift through than teams using more traditional software development frameworks. But most agile teams still find a few bugs along the way, especially if some of the development was done prior to the team adopting an agile approach. And they need an efficient way to prioritize those defects.
Prioritizing Bug Fixes: What Not To Do
Early in my career as a programmer, my boss had our entire team spend a week going through every known defect. We discussed possible causes, the severity of each bug, how often it was occuring, whether the bug had been reproduced, where in the code was the bug likely to be, and which of us should fix the problem.
We even estimated how long each fix would likely take. Not only were those estimates largely worthless but in plenty of cases, it took longer to estimate a fix than to just do it.
Having seen early the wasted effort that this caused, when I began leading teams, I started experimenting with a few other, lighter approaches.
I want to share my favorite with you today.
Prioritizing Defects by Policy: A Better Approach
Rather than taking time to reflect on each new bug individually, establish defect policies that determine how quickly a bug should be fixed.
One defect policy might be that any bug affecting all users in a dramatic way gets fixed immediately, meaning it interrupts work in the current sprint. Another defect policy may be that a bug that occurs only in extremely rare circumstances and doesn’t prevent a user from completing critical tasks gets logged and is fixed whenever time permits but without any urgency.
Creating and using policies this way is known as prioritization by policy.
As a more specific but obvious example, a team and product owner might agree that any bug that is preventing orders from being submitted on their eCommerce website needs to be fixed ASAP.
Other policies may define bugs that need to fixed by the end of the day, the end of the week, or not at all.
Define the Defect Policies
A useful way to formulate bug-fixing policies is by considering:
Defect Likelihood: How often will the problem occur?
Defect Severity: How bad is it if the problem does occur?
Notice that I refer to these as likelihood (or frequency) and severity.
Consider a hypothetical bug on Amazon.com that orders over $1 million are not being submitted because a developer made an assumption that orders would never exceed $999,999.99.
This is bad when it occurs (high severity), but I have to imagine Amazon doesn’t get a lot of orders that exceed $1 million (low likelihood).
Create a Defect Policy Matrix to Prioritize Bugs
The two dimensions--likelihood and priority--can be combined to establish the priority policy for the defect. To do this, create a simple matrix cross referencing those two factors as I’ve done here:
< 1% of transactions
1% of transactions
< 10% of transactions
> 10% of transactions
Easy, obvious workaround available
Non-obvious workaround available or workaround available only for some users
Important functionality unavailable
There are many ways you can categorize likelihood and severity. Sticking with an eCommerce site example, I used the percentage of transactions affected for likelihood. Anything estimated to affect 10% or more of transactions is a pretty big deal, so I’ve set that entire column to High or Very High.
For Severity, I used whether a workaround was present or not and obvious or hard to find. On an eCommerce site perhaps there are two “Buy Now” buttons and only one is working.
The cells in the matrix indicate what policy should be in effect for defects of the indicated likelihood and severity. In this example, I used five priorities from Very Low to Very High. In some cases you can get by with as few as three. I’d be cautious of needing more than five, although I have seen it.
Here’s how I will commonly use a five-item set of policies:
Very High: Added immediately to the current iteration even at the risk of delaying that work. May very likely need the effort of more than one team member, possibly including the whole team.
High: Added immediately to the current iteration even at the risk of delaying that work. Team decides who can best address the issue.
Medium: Added to the current iteration at the discretion of the product owner.
Low: Documented. Discussed in the next iteration planning meeting at the discretion of the product owner.
Very Low: Documented in list of known issues. Revisited only if severity or likelihood increases or at the discretion of the product owner.
Advantages of Prioritizing Bugs by Policy
The key advantage to this approach is that it greatly reduces time spent debating what should be done with each defect. Prioritizing bugs by policy does require some initial effort to create the right policies. But once those are created, prioritizing each new defect report becomes nearly trivial.
The goal with an approach like this is that prioritizing defects becomes largely objective rather than subjective. Yes, someone will have to decide how frequently a problem will likely occur, but beyond that prioritizing defects becomes no more time consuming than consulting the team’s policy matrix.
What Do You Think?
What do you think about prioritizing defects by policy? What steps has your team taken to make prioritizing defects easier? Please share your thoughts in the comments below.
When I created the Better User Stories course, my aim was simply to create a resource that would help people solve some common problems and write “better user stories.”
While I knew user stories were a problem for many agile teams, I was still surprised by the overwhelming response and demand. What’s more, since opening the doors for the first time last year, members have been kind enough to share success stories and results. Although I was expecting to hear about people improving the way they split stories or added details, people shared results I had not predicted. To celebrate the re-launch of the course today, I wanted to share them with you.
1: After Better User Stories, “colleagues started listening to me…”
If you’re interested in a course about user stories, there’s a good chance you’re already sold on their value. You know user stories are important, that they foster collaboration, that they are driven by the user’s needs, and that they are lightweight placeholders for delivering requirements.
And if everyone in your organization feels the same, then investing time to improve the process isn’t difficult. Unfortunately, some of the Better User Stories members previously had felt like pioneers for user stories. They were the early adopters in their company and although intuitively they understood the value of user stories, they struggled to articulate it to others.
Many people told us that the course had given them new ways and tools to help explain user stories so that teams and stakeholders were more receptive to giving them a go.
One member described it as being able to get his “foot in the door,” which then gave him a way to overcome his team’s initial resistance.
2: Since Better User Stories, “I have much more confidence coaching the team”
As an advocate for user stories, you’ll play a critical role in meetings, whether in a story-writing workshop, doing user-role modelling, or splitting stories. While this makes you valuable, it can also be a little intimidating. Especially if people are looking to you for answers or guidance.
A lot of people mentioned increased confidence as a one of the most important benefits. My experience is that Better User Stories members want to help others. They want to make life easier for team and improve working relationships throughout the company. Some members enjoyed that the course provided reassurance and a sanity-check that they were on the right track as they coached others. Others really valued having more coaching tools to draw on when they facilitated workshops or faced an unexpected problem.
3: With better user stories, “we’re getting much more appreciation (and freedom) from stakeholders”
Lana, who joined last year, told me something that showed up as a recurring theme when we asked members for feedback:
“I believe that user stories are the heart of the agile process because they foster collaboration between the business and delivery teams.”
Because user stories are pointers to requirements, they naturally encourage conversation, which in turn improves relations between the development team and the wider business. What we found, though, was that some members saw a significant increase in respect and appreciation from both external and internal stakeholders.
It seemed that as stakeholders enjoyed more transparency around progress, and teams had a deeper understanding of the business value, relations became a lot less strained. Stakeholders seemed to be more appreciative of the work being done, and teams no longer felt they were being unfairly watched or scrutinised
4: Now that I’ve taken Better User Stories, “other departments are asking for my help”
One of the results I really enjoyed hearing, was how members were increasing their personal value within companies and organizations. I suppose, while being a pioneer for user stories can be a bit unnerving at first, when you start to see results it gets attention. And who do you ask for advice but the person carrying a torch for the user stories cause?
We had a lot of members write in to say that they had been able to expand their role, move into different departments, and create new systems and processes that were being rolled out and adopted by other teams.
Hearing how people were experiencing this by investing in the course is some of the best feedback we could ever receive.
5: Since I joined Better User Stories, “I know I’m not alone”
Knowing how other companies are implementing agile, along with the successes and challenges they face provides valuable context for your own agile journey. However most people aren’t in a situation that provides this kind of insight.
As part of the Expert Access Level offered in Better User Stories, members have access to an online community of agile practitioners, as well as monthly Q&A calls with myself and (coming up) other leading agile experts. One member, Jim, found this community connection to be really valuable:
“I’ve taken a lot of online courses and in-person ones, but this probably had the best sense of community I’ve ever seen. The coaching calls combined with the [online] group generated a lot of community discussion. The thing that really opened my eyes was how many people are using this in so many places around the world. Everything that was posted was something I could identify with. The diversity and yet commonality of issues was remarkable. To see what’s happening on a worldwide basis was eye-opening, refreshing and exciting.”
Better User Stories Is Now Open for New Registrations (with a New Offer)
Hearing stories like these from members makes me excited to open the doors again to new members.
And this time we’re doing something a bit different.
Previously we offered 3 membership levels:
Work With Mike
This time, if you join the course before Wednesday 21st March, you can register at the Professional level and get a free upgrade to Expert Access.
What’s the difference in levels?
Quite a bit, which is why we’re looking forward to making this available to members.
When you upgrade to the Expert Access you get a 12-month complimentary subscription to the Agile Mentors Community, which includes:
A members-only discussion area dedicated to agile topics Exclusive access to the Weekly Tips archive (with more than 120 tips you can’t get anywhere else)
Monthly Q&A calls with Mike and other leading agile experts
Access to the library of 12 previous Q&A calls
A 12-month subscription to the Agile Mentors Community has a value of $600, but you get it included in your free upgrade to the Expert Access level.
If you’d like to find out more about Better User Stories, including the curriculum, course materials, and bonus content, visit www.betteruserstories.com. There is also a simple option you can select if you would like your employer to pay for your membership. Any other questions about the course? Feel free to comment below and I’ll answer.
When I asked readers to list their biggest challenges with user stories, I received hundreds and hundreds of questions and problems just on the subject of adding detail.
How do we add the right amount of detail to user stories to give the development team enough information without directing their approach?
We’re spending too much time and effort adding details to our user stories up front. How do we make the team feel more comfortable with less information?
How can we work with product owners to help them provide more specifics in the user stories without them dictating the design?
Spending too much time adding unnecessary details in user stories too early takes time away from developing the product. It also stifles creativity. Worse still, that extra time often turns out to be wasted when early details become outdated and irrelevant.
Yet, when agile teams don’t include enough detail in user stories they are vulnerable to being blamed for functionality they didn’t deliver… features that weren’t specified but that others assumed the team would understand were essential.
A Better Question about User Stories, Details, and Balance
This all makes sense. We know that adding the right amount of detail is a balance of not too much and not too little. A common phrase that guides agile activities is “just enough, just in time.” This maxim definitely applies to adding detail to user stories. But it’s one thing to understand the concept of balance and another thing entirely to gauge how much is enough and when is the right time.
And this is why one of the most common questions is:
How do I add just the right detail, just in time?
But this is actually the wrong question.
Well, not so much wrong as almost right. And I believe it’s this question that holds people back from finding a better answer.
A better question is:
How do I add just the right detail, just in time… for my team?
The Simple System for Adding the Right Detail at the Right Time to Your User Stories
There is no arbitrary rule or checklist you can use that is right for every user story, and any attempt to provide this will most likely fail when in the real world.
But there is a simple system you can use to get the answers you need for your team. I want to share it with you in this free video training.
User stories are perfect for breaking large and complex projects into incremental steps. However, finding the best way to split stories so that they fit into a single iteration is a problem that plagues many agile teams.
If you don’t split stories correctly, it throws off your velocity and estimates, and makes it harder to demonstrate progress during a review.
That’s why I created a 20-minute free agile training video that shows you a simple but effective story splitting method I developed and personally use for splitting any user story quickly and easily.
The most likely reason teams struggle with how to split user stories is that they don’t use a consistent system. This isn’t surprising to me and it’s not really the fault of the team.
If you search online for “how to split user stories,” you face an overwhelming number of options. Finding twenty ways to split a story may seem great at first. But you’ll probably find that many of those rules overlap with, or even conflict with one another. And trying to remember and evaluate twenty different story splitting strategies can certainly slow discussions down.
So, what are successful agile teams doing instead?
Many teams rely simply on their own intuition and experience to split stories. This can be OK at times. But I far prefer having a system or repeatable approach that I know will lead me to a good way of splitting a story.
The other advantage to having a system--as I show in the video--is that you can roll it out to other teams. It’s hard to scale an approach that relies solely on intuition and experience.
Not being able to split stories well also makes it hard to estimate them, which happened to Better User Stories member, Michael B.
Michael works for a consumer products company implementing e-commerce capabilities. He explained that while it initially seemed quicker to split stories using gut instinct, it created problems later:
“We’d always struggled to split large stories and get good information, particularly at the low-level. Our user stories would capture a need, but then we’d eventually need to break it down further, only to find hidden information. As a result, we were underestimating how long work would take.”
– Michael B.
Better User Stories Member
Once he had a system in place, Michael was able to change this:
“By splitting stories more effectively, there is more thinking about the purpose of the story and the result is we’re estimating more accurately."
Solving the Story Splitting Headache: What You’ll Learn in This Video
After years of working with user stories, helping teams with them, and studying what was helping teams succeed, I realized that an effective system for splitting is actually easier than most people think.
In fact, everything you need to know to split a story can be distilled into the simple approach I’m sharing with you today.
Watch the video today and discover how these 5 strategies for splitting stories can help teams reduce surprises, balance technical requirements and end-user value, and produce something shippable and valuable every iteration.
Splitting Stories the Right Way Reduces Surprises
Once the team begins work on a story, you don’t want too many surprises. Conversations, yes; but not conversations that uncover so many unknowns that progress stalls or even stops.
If you split stories and leave them still too big, iteration planning takes longer and velocity is more variable as the team is often only 90% done with a story when the iteration ends.
Discovering too late in an iteration that a story is too big can affect not just that one user story but the entire iteration:
“As we started working on a story, we would sometimes see that it actually needed to be more than one story and would need splitting out. However, because of the code management system we use, it’s much harder to do that and keep tasks linked together once you’ve started. It makes it really difficult to split after the fact and still trace everything.”
Better User Stories Member.
But that doesn’t mean you should go to the opposite extreme and have infinitely small stories. Do that and your user stories begin to look like a list of tasks.
While it might be easy to complete extremely small stories in an iteration, it can make them harder to manage and prioritize.
The five story-splitting approaches outlined in the video show you how to avoid obstacles that may be hiding in a large story without saddling the team with a long list of technical tasks.
How to Keep Technical Requirements Without Losing Sight of End-User Value
Splitting stories that focus on end-user value is all good and well, but you still need a good idea of what the system needs to do, before you can work on it. Fortunately, splitting user stories doesn’t have to be a choice between keeping the development team or stakeholders happy. You can still split stories to be small enough for the team yet big enough that stakeholders can understand their value.
In this video, I show you how to build a graphical representation of customer needs and system requirements. It’s very similar to the story-mapping process I outlined in video one of this free training series. (Missed video one? Sign up and watch it here).
Developing this at-a-glance layout of customer-driven functionality makes it much easier to split stories effectively. It highlights interdependencies so that instead of splitting along technical boundaries (such as frontend or backend work) you can see the stories needed to deliver the feature from a customer’s point-of-view. You can also use this process to know which stories of a feature can be deferred to another iteration (while still adding value) so that you’re bringing in just the right amount of work.
Which brings me to the next thing you’ll learn in this video: Splitting Stories the Right Way Helps Demonstrate Meaningful Progress
Teams can feel held hostage to the goal of delivering something potentially shippable by the end of each iteration. In fact, some teams have told me it’s just plain impossible for their products.
But, the five techniques I cover in this video will tell you exactly how to achieve something potentially shippable and of value to stakeholders--even if you’ve thought doing so is impossible on your product.
Splitting stories with these techniques allows you to go into every iteration review confident you have a set of completed features that is worth demonstrating to stakeholders.
You’ll no longer have to tell stakeholders, “We made good progress. Trust us. But there’s nothing to show you this time.” Instead you’ll have split stories in ways that demonstrate meaningful progress.