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.
Have you ever fallen asleep during a sprint review? Me either. But I can imagine it happening. How about skipping a sprint review because you knew it would be boring? No, but I’ve been tempted. And I suspect you have been, too.
I want to share four questions you can ask yourself to ensure your sprint reviews are never the type to put people to sleep or make them want to skip the meeting.
Question 1: Do the Right People Know about the Sprint Review?
If your sprint review meetings are poorly attended, we need to start with the most basic question: Do the right people know about the meeting and when and where it is?
I was once invited to speak at a company meeting in Denver. My speaking slot was to be at 10:00 A.M. and I was told to show up you at the Hyatt hotel at 9:30 so I’d have time to connect my laptop before my talk.
I always like to be early, so I arrived at the Denver Hyatt at 9:00 to be safe. But there were no signs in the lobby about the meeting. When I asked about it at the front desk, they had no record of the event being scheduled at their hotel.
I stood there for a moment wondering what had happened. And then another hotel employee said, “Are you sure it’s this Hyatt? There’s another Hyatt around the corner from us.” Sure enough, I was at the wrong place._
Is it possible you haven’t told the right people when and where to be? You probably have but it’s worth double checking.
Question 2: Are the Sprint Review Meetings Convenient?
Sometimes the reason people aren’t attending is because the meetings are inconvenient.
Maybe they’re at an inconvenient location. One of my former clients had a building that was only two floors but was very long. Meeting rooms could be as much as a ten-minute walk away and still be in the same building.
A ten-minute walk is a high hurdle if someone invited to a meeting is marginal on the benefit of attending. Teams there stopped holding sprint reviews in the nice, dedicated meeting space and instead held them in the open space around their cubicles. People had to stand for the meetings but attendance was much higher without the long walks.
Maybe it’s not the location but the day or time of the meetings. Check with those are have been invited but are not showing up to find out way.
Question 3: Are the Right Topics Being Covered in the Right Detail?
If the sprint review goes into too much detail, the meetings become tedious. If topics are covered too superficially, people stop feeling the need to attend because nothing important is ever discussed.
So you need to ask yourself if topics are being covered in the right level of detail. If not, start the next sprint review meeting by discussing it with participants. Ask them what level of detail would be most useful. Be sure to tell prior no-shows that you’ll be discussing this at the upcoming meeting. Stress that it will be their chance to guide the meetings toward the right level of detail.
A Special Consideration for Multi-Team Projects
On multi-team projects, sometimes the meetings are at the wrong level of detail because each team is conducting its own distinct sprint review. If that’s the case, consider merging some of the sprint reviews.
This results in fewer meetings. It also allows new functionality and progress to be discussed more holistically, which often leads to more useful meetings.
Question 4: Are Sprint Review Meetings Boring for Some Other Reason?
If topics are being discussed at the right level of detail, ask yourself if sprint reviews have become boring for some other reason. Sometimes this is because one participant dominates the discussion. Some people feel compelled to offer an opinion on everything. Others ramble on too long unchecked.
The Scrum Master is normally the facilitator of the review. Make sure your Scrum Master knows this and accepts the responsibility for keeping discussions lively and moving along briskly.
I like to apply the old show biz advice: Always leave them wanting more. If you are putting on a live performance, you’d prefer the audience to leave wishing there’d be just one more act or song rather than feeling the performance had gone on too long.
Err on the side of sprint review participants wishing the meeting had gone on five more minutes rather than that it was five minutes too long.
Engage Your Product Owner in Helping to Fix a Lack of Participation
A team’s product owner can be a huge ally in both getting people to attend and in getting them to participate once there. Product owners have more and deeper connections to the business-side stakeholders teams struggle to get to attend. So, solicit you product owner’s help in solving problems related to low attendance and participation.
What Do You Think?
Have you ever suffered from low attendance at your sprint reviews? What have you done that solved the problem? Please share your thoughts in the Comments below.
There is no magic template that must be used for user stories. They can be written in any number of ways. But the most popular way of writing user stories is with this template:
As a …, I … so that …..
This template originated with agile coach Rachel Davies at an English company, Connextra, in the early 2000s. It has since become a recognized standard for expressing user stories.
In this article, let’s take a look at the three elements of this standard template, why that template has stood the test of time, and the strengths and weaknesses of the template.
The Three Elements of the Standard Template
I’ve described the three parts of the standard template in various ways over the years. In User Stories Applied, I described the three elements this way:
As a (role), I want (function) so that (business value).
I later shifted to referring to the three elements as the role, goal, and reason. Ultimately I settled on just referring to them much more simply as who, what, and why. The three elements of the standard user story template address:
Who wants the functionality
What it is they want
Why they want it
Let’s look at each of these parts of the user story template.
Who: The First User Story Template Element
The users of a typical product or system can generally be categorized. As an example, I’m typing this into Google Docs right now. I could be considered a casual user of Docs. I don’t use most of its features. I’ve never clicked on its Add-Ons menu to even see what’s there. I don’t do a lot of fancy formatting because most of what I write gets moved onto my website and is formatted there. So, let’s call me a Casual User.
Others who do use those features could be called Power Users.
I usually send my blog drafts to an editor. And so, Editor could be another role when identifying the various different types of Google Docs users.
These user roles form the first part of the standard user story template. So someone developing a word processor might have a user story of “As a power user, I want a spellchecker…”
What: The Second User Story Template Element
The second part of the standard template states what is desired or needed. This is commonly stated as “I want….” In fact, for years my conference presentations and other trainings on user stories had a slide saying “I want…”
I eventually realized that was inaccurate. Sometimes the functionality being described is not something the user role wants at all. For example:
As a member, I am required to enter a strong password....
No (normal) user wants to enter a password with lots of characters, three special symbols, no repeating characters, and at least a couple of uppercase letters. At best, we understand why it’s needed, but personally I’d prefer the system should just magically know it’s me and let only me in.
So, these days I no longer include want when showing the template in courses or presentations. Instead of always being I want, sometimes it’s I’m required, forced, need to or more.
Why: The Third User Story Template Element
The final part of the standard template is why the user wants the functionality being described in the user story. This is provided after the so-that portion of the template. For example, a fully expressed version of the earlier spell checker story could be “As a power user, I want a spell checker so that I don’t need to worry about spelling misteaks mistakes.”
The so-that clause of a story is important because understanding why a user wants what is described in the what portion of the story helps the team decide how best to implement the functionality.
As an example, look no further than our spell checker story. Suppose it were provided to a team without a so-that clause as simply: As a power user, I want a spell checker. That very likely would lead a team to develop what all early spell checkers were: After-the-fact tools run on a document after it was written.
But our power user doesn’t want an extra step after finishing writing a document. Rather, the power user wants what seems more standard today: real-time correction of mistakes as they are made. What the user really wants is given by the so-that clause: the user doesn’t want to worry about spelling mistakes.
Should the So-That Clause Be Optional?
When I present on user stories during in-person courses, I am often asked to justify my seemingly contradictory view that the so-that clause is the most important part of a story yet it shouldn’t be mandatory.
I don’t consider it mandatory because sometimes it just doesn’t add any value. Consider a story about logging in: As a member, I am required to log in. What so-that clause can you add to this story that adds value or clarifies the intent of the story? Do any of these really help or are they just superfluous text added to comply with a template:
As a member, I am required to log in so that only I can access my personal data.
As a member, I am required to log in so that others can’t access my personal data unless I’ve given them my credentials.
As a member, I am required to log in so that the system knows it’s me.
As a member, I am required to log in so that hackers are kept out.
While I don’t consider the so-that clause mandatory, I do write it nearly all of the time. I reviewed a recent backlog I’d written and 62 of 64 stories (97%) had so-that clauses. A small number of occasions prevent me from considering it mandatory.
Strengths of The 3-Part User Story Template
So what’s so good about this template that it has stood the test of time? After all, a practice introduced in the early 2000s and growing in acceptance so many years later must have something going for it. I think there are four main strengths to the template.
It Covers Three of the Five Ws
I started university as a journalism major. I think I romanticized movies filled with cigar-chomping newspaper reporters—films like Ace in the Hole, Citizen Kane, It Happened One Night, and All the President’s Men. Journalists are trained that any newspaper article needs to answer five questions that each begin with a W:
User stories address three of the five--Who, What and Why. When discussing product or system requirements, it seems reasonable to leave When and Where out as the answers would usually be “right now” and “in the product.”
The Elements Are Presented in the Right Order
I think the elements--who, what, and why--are presented in the right order. Think about any story--not a user story but a movie, a novel, or an anecdote or joke you want to tell a friend. The most important thing in that story is almost always who is doing it. We call that person the protagonist.
When we watch a movie, we need to care about the protagonist before we care about the plot. I don’t care one way or the other the Death Star being blown up until I see a little of myself in Luke, Han or Leia and can relate to them.
Only after I know who, do I care about what and why. The standard user story template puts these in that order.
The Story Is Told from a First-Person Perspective
We like stories about ourselves. (Well, unless we’re teenagers and our parents are telling stories about the not-so-cute things we did when we were babies.) The next best thing to a story about me is a story about you. The least interesting is a story about the guy across town whom I’ve never met.
Stories about I and you and we and she and he are interesting.
The Beatles knew this. They very deliberately stuffed as many personal pronouns as they could into their song titles. And if they couldn’t fit a personal pronoun in the song title, they put as many as they could in the song’s lyrics.
The Beatles’ first British album had pronouns in 8 of 14 song titles (57%). In the 19 minutes and 30 seconds of those eight songs The Beatles used 325 personal pronouns, one pronoun every 3.6 seconds.
That worked so well their second album had pronouns in 64% of the titles. The Beatles then pushed it to 79% on their third album.
In an interview with Billboard magazine, Beatle Paul McCartney said this was very deliberate: “All our early songs contained 'me' or 'you.' We were completely direct and shameless to the fans: Love Me Do, Please Please Me, I Want to Hold Your Hand.”
The standard user story template starts with I, the most personal of personal pronouns. I have no basis for this claim--I’m no brain scientist--but I swear something happens when we have a user story that starts with I. We relate to that story more closely than we would if the same thing were written as a traditional The system shall… statement.
Paul McCartney and John Lennon knew this and used it to boost their careers. Agile teams do the same when using the three-part user story template.
Our Stakeholders Are Immediately Comfortable Filling in
The Blanks Before user stories came along, I loved use cases. Or I tried to love use cases. I really did love them. But I could never get the stakeholders with whom I worked to love them as much as I did.
They were just too far afield from how stakeholders thought about their work. Stakeholders don’t think about secondary actors or preconditions or postconditions. And so use cases never worked as well in practice as I thought they should.
I’ve never had that problem with user stories. I can conduct a story-writing workshop with stakeholders simply by writing As a _____, I ______ so that _______ on a whiteboard and telling them we’ve gathered to fill in the blanks as many times as we can.
Stakeholders get it. It’s a natural way of speaking for them.
Other templates for expressing stories have been proposed, and some have advantages, but most are less natural ways of speaking. For example, Behavior-Driven Development is a great way for expressing tests or specifying by example. Martin Fowler describes its given-when-then syntax as “a style of representing tests.” And it’s fantastic for writing test specifications but it’s not as good for communicating with customers. In part this is because its template is less natural. I’ve been speaking since I was 2 or 3. I don’t know if I’ve ever started a sentence with given. I’ve definitely never used given, when and then in that order in a sentence. I’ve countlessly said “I want this so that that.”
Drawbacks of The 3-Part User Story Template
There are two drawbacks to the standard user story template that are worth mentioning.
Too Many Stories Are Written as Just “As a user…”
Too often team members fall into a habit of beginning each user story with “As a user…” Sometimes this is the result of lazy thinking and the story writers need to better understand the product’s users before writing so many “as a user…” stories.
But other times it may indicate a system not well suited to user stories. This happens because too many people associate being agile with writing user stories. To be agile, they reason, you have to write user stories even when there are no users.
I worked on a financial compliance tracking system. The vast majority of what the system did would never be seen or reported. If a compliance issue was discovered, however, reports would be generated and individuals would be notified. This system benefited from user stories for that small subset of the product’s overall functionality. But user stories were inappropriate for the rest of the system.
In cases like these, teams need to use alternative ways of expressing what the product needs to do. The syntax used by job stories or Feature-Driven Development’s features might be better choices.
The Template Is Too Often Slavishly Followed
By all means, common sense needs to be a guiding principle for agile teams. When expressing something in the standard user story template doesn’t make sense, don’t use that template. Write it another way, including very possibly just free-form text.
Earlier today I wrote a product backlog item of “Change how webinar replay reminders are sent on the last day the way we discussed on Friday’s call.”
As a product backlog item, that sucks. It’s not a user story. It’s not BDD or even a job story. It’s horrible. And if it doesn’t get fixed soon, no one will even remember what bug was talked about on some forgotten phone call.
But, I knew the team would fix it soon and so what I wrote was good enough. The last thing I need would be a Scrum Master insisting I write it to follow a template created around the turn of the millennium, no matter how well that template works for most product backlog items.
What Do You Think
As a reader of this blog, I want to know what you think of the three-part story template so that I can learn how you’re using it (or not). (See what I did there?) Please share your experiences in the comments section below.
I’ve been talking to your team. Well, probably not your exact team. But plenty of teams just like them. And those teams have shared with me six things they want their Scrum Masters to do.
1. Help Them Understand the Boundaries
Agile teams are told they are self organizing. But that doesn’t always mean the same thing in every organization. For example:
Does the team have authority to add its own technical work into a sprint?
Does the team have authority over who is on the team?
Can the team change their sprint length without asking the Scrum Master?
How much money can the team spend on tools, team activities, or anything without permission?
The list is endless. Teams often struggle when first told they’re self organizing because they don’t know what it means. Help your team understand the boundaries within which they are free to operate.
2. Make Them Feel Safe
An important job of the Scrum Master is creating safety. For example, teams need to be able to plan a sprint without fear of being yelled at if they don’t finish everything they anticipated.
Teams need to produce high-quality work (however that is defined in the organization) but should know they won’t be in trouble if an honest mistake allows a bug into production.
Teams need to be able to answer truthfully when asked, “How long will it take to build this set of features?” When teams feel pressured into giving artificially early answers, everyone loses when the features are delivered later than promised (but probably earlier than the team might have said if they’d felt safe to do so).
3. Praise Them
Everyone likes being told they’re doing a good job.
I took my dogs for a walk before sitting down to write this today. As we walked, we passed a woman with a beautiful brown Labradoodle. I said, “You have a beautiful dog.” And she lit up, beaming. I doubt she contributed much to her dog being beautiful. It’s not like they share any DNA. But she obviously appreciated the compliment very much.
Your team members are the same. When one does something good, let them know. Even a simple, “nice job,” can help. Be sincere, of course, but once you start looking for opportunities to praise team members, you’ll find plenty of them.
4. Support Them
Your team wants your support. You know part of your job is to remove impediments, but even more you should strive to remove issues before they become impediments.
Supporting your team goes beyond dealing with impediments. Team members feel supported when you are always honest and fair with them. When you tell a team member you’ll do something, follow through by doing it. You help keep them accountable for their commitments; hold yourself to the same (or higher) standard.
Be approachable. If you’re in a bad mood all day, you can’t expect team members to come to you when they need help.
Talk to team members. Don’t talk so much that you get in the way of them making progress but you should be aware of how each person is doing during the sprint. Know when to offer assistance even if that’s just to listen or to bring someone a cup of their favorite coffee one morning.
5. Make Them Look Good
The worst Scrum Masters I’ve encountered all shared one trait: They thought it was all about making themselves look good. These Scrum Masters would start sprint reviews by saying things like, “Let me show you what I had the team build for you.”
The Scrum Master’s job is to make the team look good. Not artificially but by being good. Good Scrum Masters help team members be the best they can. They then make sure the organization knows that team members are doing good work.
6. Know When to Break the Rules
The rules of Scrum are minimal but they exist for good reasons. Each helps a team be agile and increases the likelihood of success. But, as the saying goes, rules are meant to be broken.
And your team wants you to break the rules when it’s appropriate to do so. Common sense needs to prevail and in some situations, rules get in the way of common sense. A good Scrum Master recognizes those situations.
For example, never extending a sprint is a rule I follow. Usually. Have I broken it? Yes, not often and always for a good reason.
Three hours is the maximum duration of a sprint retrospective. Ninety-nine percent of my retrospectives are done in less time, usually far less time. But have teams I coached broken this three-hour rule? Yes, occasionally when a really hot topic was being discussed and it seemed better to continue than to postpone a needed conversation.
You Can Be a Great Scrum Master
There’s nothing secret, magical or mystical to being a great Scrum Master. Much of it is doing for your team what you’ve appreciated past leaders or managers doing for you.
What Do You Think?
What do you think is missing from my list? If you’re a team member, what more do you want from your Scrum Master? If you’re a Scrum Master, what did I miss that your team wants from you? Please share your thoughts in the comments below.
Most teams don’t finish everything they plan to finish every iteration. Management, or even Scrum Masters, tend to respond by asking teams to plan better during their sprint planning meetings.
This is often the wrong response.
Why Teams Can’t Plan Sprints Perfectly
Not everything is predictable. The team may be interrupted more, or less, during the sprint than they anticipated during the sprint planning meeting.
Similarly, a team cannot perfectly anticipate every task that will be needed. They may fail to identify some tasks that are necessary or they may identify tasks that turn out not to be needed.
For example, after I write the first draft of this blog post, I will send it to my editor and she’ll return it to me to review her edits. I estimate we’ll need one round of edits and revisions. But sometimes my first draft really sucks, and we need two (or more) rounds of edits and revisions.
I typically plan on one round of edits because that is normally enough. But that means I sometimes am missing tasks from my blog writing plan. However, if I planned for two rounds of edits for every blog post, I would sometimes have identified unnecessary tasks.
It seems I just can’t get it right.
The Problem with Thinking Harder
Neither can your team. No matter how often or stridently team members are told to “think of everything,” they can’t.
The good news: They don’t need to.
What to Do in Sprint Planning Meetings Instead
Instead of attempting the impossible and trying to identify and estimate every task that will be done in a sprint, the team should instead quickly identify only the main tasks.
Think about this way: Suppose you are planning your first trip to France. Paris will, of course, be one of your stops. But you also want to visit Nice, Cannes, Marseille, and others. How many days should you spend in Paris?
You don’t need to map out a complete hour-by-hour itinerary to decide how much time to spend in Paris. Making a rough list of the most important things you want to see or do in Paris would help you decide whether five or seven days is best, considering all else you want to do on your trip.
It’s the same for an agile team during its sprint planning meeting. Identifying the major tasks necessary to get done is sufficient for deciding how many and which product backlog items can be brought into the sprint.
Target Identifying About Two Thirds
In my experience, good agile teams can successfully do sprint planning by targeting about two-thirds of the tasks that will ultimately be completed during the sprint.
I want to be really clear about that: I’m not saying they plan about two-thirds of their available time. I said they identify about two-thirds of the tasks they’ll ultimately do. Those would be things like
Code this (crucial) thing
Test that (crucial) thing
Update the design based on user feedback
Meet with key stakeholders about some topic
Add this field to the report
For example, if a team will ultimately complete 60 bits of work during an iteration, identifying 40 of them during the sprint planning is sufficient for a well-planned sprint.
Returning to our Parisian holiday, identifying 8 of the 12 things we’ll ultimately do in Paris would be enough.
It’s worth repeating that the items identified should be the main, bigger, and more easily identified activities. That means that identifying two-thirds of the tasks may represent 80–90 percent of a team’s available working time during a sprint.
How Many Tasks Should a Team Do in a Sprint?
Let’s turn the vague advice of identifying two-thirds of a team’s tasks into something more directly usable.
To do that, imagine how wonderful life would be if every day every team member said in the daily scrum, “Yesterday I did exactly this one thing and today I’ll do exactly that other one thing.”
Life would be wonderful if every day every team member finished exactly one task. For example, a six-person team running a ten-day (two-week) iteration would complete 60 tasks (6x10).
That means in this example, team members would target identifying around 40 of their eventual 60 tasks. The remaining tasks will be identified naturally during the sprint.
Don’t Plan Every Detail During Sprint Planning Meetings
If you follow this advice, team members probably will not plan as many tasks as they are accustomed to doing during the sprint planning meeting. So the sprint may seem less full at first. But the reality is, it won’t be.
Returning to our holiday, identifying only the main things you’ll do in Paris doesn’t mean you’ll be sitting on the Champs-Élysées twiddling your thumbs with nothing to do for the last two days of your trip.
Rather, you’ve identified the main activities of your holiday, knowing that once in Paris you’ll find plenty of additional things to joyfully fill any unplanned time.
The same is true for a team that identifies only the main activities of a sprint. Unplanned time will be filled with the smaller tasks that are best identified during the sprint.
The advantage of working this way is that sprint planning meetings can be done more quickly with less frustration and no loss of accuracy in planning the sprint.
I wrote a book on estimating and planning. Trust me: if anyone in the world wants to be in a planning meeting, it’s probably me.
Yet far more I find myself coaching a team to spend less time in its sprint planning meetings rather than more.
All too often, team members become obsessed with trying to identify every last thing they’ll do in a sprint. You don’t need to know you’ll sip coffee at the Café de Flore on Thursday from 11:00 – 11:25 to plan your trip to Paris.
What Do You Do?
How thoroughly does your team attempt to plan its sprints? Would you say you spend too much time, too little time, or just the right amount of time in your iteration planning meetings? Please share your thoughts in the Comments section below.
Scrum’s great. And I’m very closely associated with Scrum, since I co-founded the Scrum Alliance, co-taught the very first Certified Scrum Master course, and still teach many Certified Scrum Master and Certified Scrum Product Owner courses.
But, as great as I think Scrum is, I don’t think Scrum is right for every team in every situation.
In some situations, other approaches are called for. Usually it will still be some variant of an agile approach. Most commonly that means Kanban.
And so, I’m writing to introduce a guest post on Kanban.
This post is from Brendan Wovchko, whom I’m happy to call a friend. Brendan is an expert at both Kanban and Scrum. He and I have co-trained together, and I always appreciate his openness to considering each team’s unique situation when advising them.
He knows that Scrum and Kanban each can be best for different situations. And in the following post he’s going to share reasons to favor Kanban in some situations.
I’m frequently asked by my workshop participants to weigh-in on their team’s debate between Scrum and Kanban. I always find their questions interesting because their assumption is that Scrum and Kanban are somehow enemies.
As an agilist, I value experimentation over prescription. I don’t want someone to tell me what’s best for a specific team, I want to prove it.
A truly agile team will experiment with a lot of ideas to find which works best, not just adopt the first thing they try. Scrum and Kanban aren’t competitors, they are experiments every team should try.
While that is true, I recognize that many teams have limited liberty to experiment. If you work for an organization that won’t tolerate small failures in order to discover big productivity gains, I understand! If that’s you, I’m willing to bend my rule about prescription and offer some advice on five conditions under which I’ve found Kanban to be a better fit than Scrum.
1. Low Tolerance for Change
Over the years I’ve encountered many organizations that are brittle to change. They’re comfortable with the way they do things even if they aren’t getting results. Their solution isn’t to rethink how they work, it’s usually to make their teams work longer and harder—which isn’t a real solution. Scrum is a threat to brittle, change-adverse organizations primarily because of how quickly it transforms roles and meetings.
Kanban doesn’t use transformative change, it embraces evolutionary change. Kanban employs a start with what you do now mindset that introduces teams to the shallow end of the pool before taking them toward the deep end of maturity. Kanban doesn’t require any changes to roles or meetings when first getting started.
2. Obvious at All Levels
The primary advantage Kanban has over Scrum is that it is immediately intuitive to anyone. A Kanban board is an instant sense-making device. It requires zero explanation to understand. However, Kanban’s primary advantage is also its biggest flaw. It’s easy to be fooled by Kanban’s hidden sophistication. Kanban is far more sophisticated than a simple tool for visualization. Kanban is built for speed but most teams will never master the behaviors that produce those results because their commitment to learning Kanban stops at visualization.
3. Fluid Priorities
Scrum produces the best results when a team commits to a batch of work and is empowered to remain focused for the duration of their iteration. The success of Scrum requires informed and empathetic stakeholders who are bought-in to being agile.
Kanban is able to survive conditions where agile culture doesn’t yet exist because it encourages optionality. A Kanban team prefers to not commit to work in batches and they don’t commit to work until they start it. This means a Kanban team can be maximally flexible to respond to emergencies or changing priorities without needing to renegotiate commitments.
4. Small Teams
The ideal size of a Scrum team is a two pizza team. This ensures that a team is small enough to be efficient and large enough where the time investment in meetings makes sense. If your team is smaller than a two pizza team, Kanban is the best option.
5. Complex Collaboration
Scrum has changed the way the world thinks about work. My favorite attribute of Scrum is the cross-functional team. The idea that a team is comprised of people from different departments and disciplines is a game changer.
In the case of software development, it’s not just engineers and testers anymore. Today, we have user experience, visual design, writing, editing and many other activities.
If your team has a large number of activities, the strategies of sprinting ahead or using a scaling framework may introduce unnecessary complexity and delay.
Kanban doesn’t utilize time boxing to create predictability, it uses lead time—so it is capable of sustainably supporting an unlimited number of activities and collaborations.
I’d continue to encourage you to resist the idea that Scrum and Kanban are competitors or enemies. Both are a means to help teams and their stakeholders achieve sustainable success. Don’t assume that whichever you best understand or most frequently use is superior. Adopt a true agile mindset and experiment with both!
Will you take 2 minutes to tell us about your experience with kanban?
Trying new methodologies can be key in succeeding with agile.
But that doesn’t mean it’s not challenging.
Have you tried Kanban with your team?
Have you experienced any challenges using it?
If so I’d love to hear from you.
Would you take two minutes and click the link below to take a short survey?
By this point, most people seem to understand that multitasking is a myth and does not boost productivity.
It will undeniably take me longer to write you this email if I am concurrently attempting to finish an expense report, clean my kitchen and read yesterday’s sports news.
But we have yet to extend this thinking to our organizations.
Multi-Tasking at the Organizational Level
Just as individuals get less done when they attempt to multitask, organizations accomplish less when they attempt to do too many things at once.
Organizational multitasking is attempting to do too many projects concurrently.
I mentioned this to a senior vice president of a large company a few years ago.
She said, “Follow me,” and walked me into a large, theater-style meeting room where she and her direct reports had recently completed an annual planning exercise.
Sticky notes, each representing a project, dotted a 40-foot wall. Long lines were drawn to the right of each, representing the expected duration of the projects.
She asked, “Do you think we’re doing too many projects?”
I was far enough away I couldn’t read a single word on the sticky notes. But so many projects were on the wall, I simply said, “Probably.”
She told me she thought so, too.
And the next morning, all of her direct reports returned to that room where she said, “We’re trying to do too much. Start taking things off the wall.”
Everyone looked relieved as they started removing the lowest priority projects.
I followed up with her at the end of the year and asked how the year had gone and whether reducing the number of concurrent projects had helped.
“We had our best year ever. But we didn’t go far enough. We should have dropped more projects.”
Steve Jobs Focused on the 3%
When Steve Jobs returned to Apple in 1997, there were 350 products being developed. Within two years, Jobs reduced that by 97%, down to only ten products.
Every time an organization says yes to a product, it is saying no to some other product. Or at least it should be saying no. Often the organization says yes to both products and makes unbearably slow progress on both.
Instead, focus on the higher priority product and get it out. Only then should you start the second.
At the 1997 Worldwide Developers Conference, Steve Jobs addressed this the idea of focus by saying, “When you think about focusing, you think, ‘Well, focusing is saying yes.’ No! Focusing is about saying no.”
Forty Developers Shouldn’t Work on Eighty-Five Projects
One of my clients was struggling with this. On a pre-visit call they’d told me they had 40 developers. But in my first meeting with them, they said they had 85 ongoing projects.
I quickly flipped back through my notes and said, “But when we talked on the phone a few weeks ago, you said you have 40 developers.”
And my client said, “Yeah. 40 developers. 85 projects.”
He didn’t seem to think this was a problem until I pointed it out.
This was a small company and most new projects were initiated by a request from the CEO. I got him to agree that he’d only allow one new project to start for every two that finished.
I put no restrictions on him regarding the size of the projects. But I knew this would gradually bring down the number of ongoing, concurrent projects in that organization.
He wanted to know how long he’d have to abide by that rule. He was expecting me to give him a number of projects—perhaps 40 or 50 or 30, I suspect.
Instead I told him to keep starting one new project for every two that finished until he felt that every project was getting done fast enough. That would be the sign that the organizations could handle additional concurrent projects.
It was hard, but this CEO and organization lived with that rule until they were down to 18 concurrent projects, less than a quarter of what they’d started with.
The CEO, as well as senior developers, confirmed that things were going better than they ever had before.
This is absolutely my experience as well: organizations that work on fewer projects at a time get more done.
Focusing your organization on its most important projects, and delaying work on the less important, is a surefire strategy for delivering the most value as quickly as possible.
What’s Your Experience?
Is your organization doing too many projects at the same time? How would focusing on the smaller set of most critical projects change your world? How have you been able to convince people? Please share your thoughts in the comments below.
A common measurement of an agile team is whether team members finish everything they planned in the iteration.
There’s nothing wrong with assessing how adept a team is at finishing what it thinks it can. But no team should be expected to finish everything every time.
That is unrealistic and leads to teams under-committing so they can safely deliver everything.
Excessive Expectations Can Introduce Dysfunctionality
Consider a team I know whose boss (the CEO) told them that if they ever failed to finish everything, he would “take corrective action, up to and possibly including termination.”
That team is not going to pull an aggressive amount of work into their iterations. They’ll try to select enough that they don’t get in trouble for being lazy but not so much that they risk not finishing it all.
An Appropriate Target
I find a good goal for a team is to finish everything they say they will about 80% of the time. That is a good degree of predictability for the business without being impossible for some teams to achieve.
To be really clear, a good agile team should finish 100% of what it plans in 8 out of 10 iterations. I’m not saying a team should finish 80% of its planned work each iteration. That is very different.
Successfully finishing everything every time will be impossible for highly interrupt-driven teams. If a significant portion of your team’s job is to respond quickly to issues, you may want to target a lower percentage.
Don’t Plan It If You Don’t Think You’ll Make It
When trying to finish 100% of its work, 80% of the time, the team should feel like they’ll succeed while understanding, realistically, they won’t every time.
I like to think of it as analogous to a basketball player shooting the ball. A player shouldn’t shoot the ball unless he thinks he’ll score. But, even the greatest player will understand that not every shot is going in the basket.
A great basketball player may make 40–50% of his shots. That’s not enough predictability for most teams, which is why I recommend targeting 80%.
What’s Your Experience?
How does your team do at finishing what they say they’ll do? Please share your thoughts in the comments below.
You should always strive to keep your product backlog small and manageable. With too many items on the product backlog, three problems arise:
First, it is harder to work with an excessively large product backlog. Time will be lost looking for items. (“I know it’s in here somewhere.”) Prioritizing the backlog will take longer. Duplicate items will appear as it will be easier to add an item “just in case” rather than be sure it’s not already listed.
Second, the development team barely notices any progress they make. A team that finishes 10 of 50 product backlog items can sense that they’ve made progress. A team that finishes the same 10 but out of 1,000 items will not feel the same sense of accomplishment. They will begin to wonder if it would matter if they had only gotten 9 done instead.
Third, someone spent valuable time creating all those product backlog items. Having visibility into the future a bit is great. How far depends on a lot of factors but many backlogs attempt to provide insight too far into their products’ futures.
Because these problems of an overly large product backlog can be so harmful, I’d like to present four things you can do to keep your product backlog to a more manageable size.
Delete Things You’ll Never Do
The first thing you should do to keep your product backlog small and manageable is delete items you’ll never do.
I fully acknowledge this can be hard to do. For years, I worried that if I deleted things, I’d walk into the office one day and my team would say, “We’re caught up. What next?” and I wouldn’t have an answer because I’d deleted all the long-term items.
I was finally able to let this fear go by realizing: I can come up with new ideas faster than they can develop them.
I encourage being fairly ruthless in purging items from your product backlog. If you don’t think you’ll realistically ever do it, just get rid of it.
Otherwise, a product backlog just accumulates more and more over time. That task of “learn to dance the Macarena” that’s been on my personal backlog since 1995 just got deleted. By this point, it’s not happening.
Keep Items You Aren’t Ready for Off the Product Backlog
For a handful of years, I’ve had a lot of success keeping product backlogs manageable by maintaining a separate list of items that the product owner wants but isn’t truly ready to have the team work on.
I refer to this as a holding tank. A holding tank allows me to restrict the product backlog to items that are desired immediately. The holding tank contains items that are either not quite ready or may not be needed after all.
I think of the difference like this: The product backlog contains all the things that the product owner would pay the team to work overtime tonight on and deliver.
There’s no chance a team can complete them all tonight. I just encourage thinking of it that way because these are the items that the product owner knows are needed and would be willing to pay for right now.
The holding tank contains things the product owner probably wants but either hasn’t thought through in enough detail or may decide aren’t needed after all.
I’ve found this approach extremely helpful because it leads to an immediate reduction in the size of the product backlog as items are moved from it and into another temporary holding place.
Metaphorically, you can think of the difference between a product backlog and holding tank as simply a line drawn below some item in the product backlog. Above that line are the items the product owner would pay the team tonight to deliver; below it are items that could change or aren’t well understood yet.
More practically, what I’ll do in whatever tool I’m using is create a second project, name it the holding tank, and move items to it from the product backlog.
Doing this allows the team to focus on the much smaller set of items that form their product backlog.
Periodically Review the Product Backlog
The third step in keeping your product backlog to a reasonable size is to institute a regular review process. Nothing fancy is needed here. It can be as simple as the product owner reviewing the product backlog and deleting or moving items as described above. I think doing this quarterly is best.
Don’t Add Things Unless You Plan to Do Them Fairly Soon
Finally, if you want to keep your product backlog small and manageable, you need to be disciplined in not adding items to the backlog unless you fully intend to do them.
Most product backlogs become unwieldy because it was easier for a product owner to say, “I’ll put it on the product backlog” than to tell someone their feature would never see the light of day.
To keep a product backlog in good shape, product owners need to learn to say no or not now. I’ve found that the other tips in this article help them in doing that.
What’s Your Experience?
Have you worked with an unwieldy product backlog? Do you have any additional tips for keeping a product backlog small and manageable? Please share in the comments below.
Organizations adopt an agile approach for many reasons. Some hope for greater productivity and a reduced time-to-market. Others for more successful products. Still others adopt agile to increase collaboration between developers and business people, to improve quality, or to increase team member job satisfaction.
And, of course, many organizations adopt agile in the hope of achieving some combination of these benefits.
But, for as many benefits as there can be to agile, there seem to just as many fallacies. In this article, I’d like to bust six myths about agile product development.
Myth #1: Isn’t Agile Just for Software Development?
This is an intriguing myth because Scrum is the oldest agile approach and Scrum’s origins are in physical product development. Some of the original Scrum projects were photocopiers, a Honda car, and cameras.
Agile these days is used for all forms of product development, from physical products to cloud-based software-as-a-service.
But beyond product development (both hardware and software), agile is being used successfully by
Marketing teams to plan and execute campaigns
Attorneys to manage cases and workload
Organizational transformation efforts, in particular when transitioning to agile
Senior leadership teams to manage their organizations
Families for improving time together
Couples planning weddings
And, of course, many more. Any project with a high degree of uniqueness (you haven’t done it ten times before) and complexity is well suited for agile. If you find yourself hung up by references to software in published in documents such as the Agile Manifesto, just substitute the word products. Change working software, for example, to working products and read it again: [We value] working products over comprehensive documentation. It fits perfectly. Why? Because agile works with all kinds of products—software is only one of them.
Myth #2: Is It True That Managers Have No Role in Agile?
I think this myth persists because too many managers spend a lot of time doing things they shouldn’t be doing, regardless of being agile or not.
For example, managers often work down at the level of assigning tasks to individuals. When they learn this isn’t something they should do in agile, they feel like part of their job has been taken away.
No: Part of the job has not been taken away. Things like assigning tasks should never have been part of the job in the first place.
Managers should be focused on creating the environment and culture a team needs to thrive. Their time should not be consumed with minutiae like who will work on which task.
Peter Drucker was perhaps the leading management theorist of the 20th century. He is perhaps best known for the idea of management by objectives and creating the acronym SMART for goal setting in which goals are Specific, Measurable, Acceptable, Realistic and Time-bound). Drucker said managers have five jobs:
Organize people and work
Motivate and communicate
Sure, in some organizations, some of these responsibilities may be diminished. But others—such as developing people—become more important.
In all the years I’ve worked with agile and agile organizations, not one has decided to fire all managers. Yes, some managers have moved into the more focused roles of Scrum Master or product owner, but there is still a role for management in agile.
Myth #3: Can’t Stakeholders Introduce Change Whenever They Want?
Not surprisingly, the myth that stakeholders can introduce change any time they want is most commonly believed by stakeholders themselves.
Development team members understand that introducing change at the wrong time comes with a cost.
Consider ordering a meal at a restaurant. You tell the waiter you’d like the chicken. Then instantly say, “No, make that the salmon instead.”
There is no cost to this change.
There is, however, a cost if you change your mind later. If you tell the waiter to change your meal from chicken to salmon after the kitchen has begun cooking the chicken, there is the cost of wasted food (which the restaurant may well charge you for).
The cost is more obvious if you eat half of the chicken before telling the waiter you’d like to switch to the salmon.
A stakeholder introducing change into an iteration is like the diner changing from chicken to salmon. If the change is introduced at the right time, there may be little or no cost. Introduced at the wrong time, though, and there is a cost.
Being agile cannot eliminate all costs of stakeholders introducing change. However, good agile teams can reduce the cost of change regardless of when the change is introduced. Common ways of doing this are:
small product backlog items
Finishing each product backlog item as quickly as possible, usually by minimizing the number of items being worked on concurrently
None of this is to say that teams shouldn’t welcome appropriate changes. Some stakeholder-requested changes can be very important. But, the benefit of making each change needs to be assessed against the cost of changing and that cost is not always zero.
Myth #4: Doesn’t Everyone Need to Be a Generalist on an Agile Team?
For some reason, a popular myth about agile is that every team member needs to be able to do everything.
This is entirely false.
Agile teams don’t need everyone to have every skill. Instead, what agile teams need is to value any individuals who do possess skills in multiple disciplines.
To understand the falseness of this myth, consider a well-run fancy restaurant. From watching too many TV cooking shows, I’ve learned such a restaurant may have a pastry chef. The pastry chef is skilled in making pastries, desserts, bread and other baked goods.
This sounds like a highly skilled but specialized role. Another specialized role in the kitchen could be the saucier, who prepares sauces, stews, and other similar items.
In a well-run kitchen, it would be nice if the pastry chef could help the saucier, perhaps by slicing some onions during a sudden onion shortage emergency. But neither the pastry chef nor the saucier would be expected to be fully capable of doing job of the other.
In today’s world of complex technologies, it is unrealistic to expect team members to be fully proficient in all the skills of the team. Instead, good agile teams learn to value multi-skilled team members.
Having a few team members with multiple skills helps manage the balance of types of work. That is, sometimes the team needs more testing capacity. Having a team member or two who can shift into doing helps incredibly.
But this can be accomplished on most teams even if a few team members are truly specialists and adept at only one discipline.
Myth #5: I’ve Heard that Agile Teams Don’t (or Can’t) Plan.
Most good agile teams do plan. But that planning is often less visible than on traditional projects because agile teams don’t have an upfront planning phase.
Instead, good agile teams conduct planning as a series of smaller, recurring activities that ensure their plans always reflect the realities of the current situation.
In this way, teams develop plans the same way they develop products: by inspecting and adapting.
For any agile team, its plan should project no further into the future than absolutely necessary for making important decisions. But most organizations and teams have a plan to approximate at some level what is coming next and when it’s coming.
In fact, despite this myth, agile teams have an easier time creating reliable plans because agile teams get earlier insight into how quickly they are producing software.
Consider a traditional team with analysis, design, coding and testing phases. If lucky, that team may delay committing to a plan until the end of the design phase. But at that point, this team has no idea how fast they are at coding and testing—they haven’t done any of those activities yet.
In contrast, an agile team turns the crank of the entire development process every iteration. Each iteration includes a little analysis, design, coding, and testing. This gives the agile team more and earlier insight into how quickly it can turn ideas into new features.
Myth #6: Don’t Agile Teams Create Products with No Architectural Plan?
It’s time to bust our final myth: the myth that agile teams don’t architect or design their products.
Agile teams definitely design their products. But, in the same way they plan incrementally, agile teams architect and design incrementally. This allows them to inspect and adapt their architectures and designs so they become the best possible.
This means there is no upfront phase during which all architectural decisions are made. Instead the architecture of a product emerges over time.
This occurs by technical team members focusing first on any aspects of a product they consider risky. For example, if delivering a product with the needed throughput will be challenging, the team and product owner would elect to work on functionality early on that reduces that risk.
In this way, the emergent architecture of an agile product is also intentional. The architecture doesn’t just show up one day. It emerges gradually and guided by the intent of the technical team members.
This means that agile products do possess an underlying architecture. But decisions about that architecture are made as needed through the course of the project rather than being made entirely at the start of the project.
What Other Agile Myths Need Busting?
I’ve busted six myths surrounding agile product development. What other myths have you encountered in your organization? Please share your thoughts in the comments below.