- A Little More Coaching for You
- Objections to Scrum
- Making the Transition
- Problems after the Switch
- Sizing and Estimating
One of the biggest advantages of having a coach to help you through the Scrum transition is having ready answers to little questions that pop up. This section is a collection of such questions I have gotten in some form over the years. In some cases the answers did not seem to fit anywhere else. In others they repeat information elsewhere on the site, but that’s okay: Sometimes we humans have to hear things different ways and multiple times before they sink in. In my teenage job as a swim instructor, I half-joked that I had 50 ways to teach the freestyle, because that was what it took to reach everybody! The questions are organized by problem area but otherwise are in no particular order, so loop back to the Contents list if you don’t want to read through them all.
Isn’t Agile just another management fad?
I understand this question, having witnessed plenty of management techniques come and go over 30 years, many actually repackagings of previous techniques. Often the basic concepts are scientifically valid, but keep coming back in different forms because companies don’t actually implement them.
Agile is a partial repackaging, but has passed the “fad” stage of maturity. The concept of iterative development in software was proposed in the early 1970s; some methods date at least as far back as the 1980s, and the Manifesto has been around for more than 15 years. Demand for experienced Agile coaches and Scrum Masters in the labor market remains very strong. More importantly, Scrum enacts many findings from academic and field research that date back as many as 60 years, such as:
- Properly structured self-managed groups make better decisions over time than a single expert, or teams closely directed by a boss.
- Teams with formal work processes, such as project management and documented procedures, outperform those that don’t.
- Project plans going out more than a few months rarely reflect the final reality of the work.
- People who sit in the same general area outperform similar teams spread across buildings, or worse, time zones.
Perhaps the best sign is that Scrum has evolved significantly from its first popular formulation in Agile Software Development with Scrum. A true fad is adopted by large numbers fairly quickly, remains relatively static, and disappears as a result. Other teamwork solutions last but don’t evolve, usually “quick fixes” like personality tests that don’t have long-lasting impact on performance, but live on because they are easier than real change. We now have at least a decade of measurable performance-improvement history from Agile, and adoption continues slowly but steadily.
No. There is no quick fix to problems that have grown up among multiple human beings over multiple years. My former consulting practice was based on proof that single-shot solutions promoted by most teambuilding companies have zero long-term impact on team performance, and thus are a waste of time and money. Scrum is not a magic pill that removes all problems. You have to keep taking the Scrum medicine over months. You need to take other steps to improving life for your members and customers as much as possible.
I often say when delivering training, “Agile does not necessarily solve problems, but it makes their causes more obvious.” Tracking all of your work the same transparent way, making liberal use of dependencies and blockers, and forcing priority choices highlight points of trouble.
Still, a disciplined approach to Full Stack Scrum™ will relieve a lot of the symptoms you were seeing. Like any new skill, it takes work, self-discipline, and practice to master, but that effort pays off many times over by instilling a group of good business habits.
There is plenty of anecdotal evidence that project teams switching from waterfall or no project management to Kanban get faster and improve quality. I won’t bother citing sources because a Web search will bring up plenty. Some case studies and at least one journal article I found suggest that Kanban can be easier to spread within a company than more complicated methods like Extreme Programming and Scrum. The explanation for that is simple. Because Kanban is simpler, it is easier to learn and requires less self-discipline to follow.
Despite all the arguments, I have not yet found a single objective comparison of Scrum and Kanban using the scientific method to eliminate bias from the results. Unless a body of research literature builds up and proves me wrong, therefore, I will rely on the well-established literature on teamwork that suggests to me that Scrum is more effective for project work.
A key finding is the power of deadlines in human psychology. Scientific evidence detailed in The SuddenTeams™ Program (under “The Team Mesa“) shows that an earlier model of team development, called “Forming, Storming, Norming, and Performing,” rarely reflects team reality. Instead project teams tend to wander until roughly halfway through the effort, and then begin to normalize their processes and perform relatively better until the project’s end. A major review of the research on teamwork by two scientists concluded teams that don’t have deadlines typically don’t get around to performing radically better. In SuddenTeams, I suggested managers of nonproject teams create deadlines in the form of process improvements to overcome this problem. Kanban has no deadlines, or at least no short-term deadlines which create more internal motivation than longer release deadlines.
Social psychology research has proven that group discussion greatly improves decision-making, and making written commitments to peers improves delivery rates. Kanban, and attempts to combine it with Scrum (“Scrumban”), do not have nearly the same level of team collaboration and group discussions as Scrum. In most cases members do not collectively review requirements for clarity and priority or agree on the dependencies, risks, and high-level approach to completing them. This loses the power of multiple perspectives that have been clearly demonstrated by diversity studies, and leaves unknown productivity- and quality-sapping issues that could have been prevented.
This is a common complaint about Scrum, but having done waterfall projects long before I got into Agile, I think the complaint is based on a misconception. The evidence is powerful that teams, and more so larger organizations, that use formal project management outperform financially those that don’t. And formal project management requires a lot of meeting time. Most people never participated in disciplined project management, so they don’t realize how much time they would have spent in project planning meetings—before they could even start research and development!
Those who have done real waterfall probably never calculated how much time they wasted planning work packages that ended up getting redone or replaced. Nor does anyone realize how much time they don’t spend fixing bugs or gold-plating in Scrum because the team took less time than that to understand the deliverable thoroughly before starting. Then there’s the overtime required when the team is not working at a sustainable pace, and has to make heroic efforts to try to meet arbitrary deadlines.
All this “ghost time” people forget about is saved in part due to the shorter time cycles of Scrum; more regular check-ins with each other and with a customer; and more frequent “lessons-learned” meetings. There also is scientific evidence that up to a point, teams that spend more time talking things over make better decisions over the long term. In one study, teams in a simulated airport security experiment were more likely to spot weapons in bags if they took more time talking than the less successful teams. This idea is the basis for “crowdsourcing,” gathering many perspectives in a formal way that increases decision quality. I have seen numerous occasions where questions from the newest member of a team, or from someone with a different work background than an expert, changed the team’s or expert’s direction radically.
Shortcuts like letting the people doing a story groom the story by themselves loses out on the value of multiple perspectives. Also, in an environment emphasizing that the entire team is responsible for failed stories, these alternatives force people who had no input on the stories to take responsibility for them anyway. And if one team in a program struggles more than the others to deliver its stories consistently due to these shortcuts, individual blame becomes almost inevitable within the team.
By investing roughly 10% of your time into planning, you save far more overall. Anyone with retirement savings understands this tradeoff.
More than once people in organizations I worked with have objected to Scrum as “micromanagement.” I had to bite my tongue: Anyone who thinks Scrum is micromanagement has led a charmed life. In my first career as a journalist, I once wrote an article with an editor literally standing behind me and asking, “Are you done yet?” I have heard first-hand complaints of experts in their fields required to run everything they produced past less-expert managers and getting them back marked in red. That is micromanagement!
The definition of micromanagement from my Random House Webster’s Unabridged Dictionary is to “control with excessive attention to minor details.” In Scrum implemented per the Agile Manifesto, no one is controlling your behavior. No manager even knows what you are doing day to day, unless they attend your scrums! Your team does. However, you choose (or agree to) the tasks you will deliver sometime within a sprint, and day to day the team only knows what you have decided to do. How you do so is described in tasks so generic, most of them can be copied among similar stories. The detailed actions are left to you. The solution you create is entirely up to you and those you choose to work with on it.
I’ll fall back on my journalism days to explain the difference between Scrum and micromanagement using the “Five W’s” (and an “H”) regarding control over your daily tasks:
|Who does the task||Manager||Worker with team input|
|What is the task||Manager||Team with worker input|
|Why do the task||Manager (often not relayed to worker)||Requestor, in story statement|
|Where to do the task||Manager||Worker|
|When is the task done||Manager||Worker with team input|
|How is the task done||Manager||Worker|
Clearly in properly implemented Scrum, no individual is controlling most of your choices. No one other than your co-workers even knows the details. So this objection to Scrum fails on both aspects of the definition of micromanagement.
People who make this objection are those unaccustomed to having anyone provide input on, or even know, what they are doing on a daily basis. Working on a self-organizing team certainly adds limitations to their preferred style. To do group work efficiently, as explored throughout this site, each member does have to be transparent about what they are doing, and make decisions about that work jointly with the group. This truth pre-dates Agile by millennia. There are some jobs that can be done start to finish by one person with near-absolute freedom over the method and solution chosen. A very low percentage of research and development jobs fit that description. Almost anyone who chooses a career in R&D and truly cares about pleasing customers is choosing to share significant information and decision-making with their team. Of the options for doing that, I believe Scrum in a fully Agile organization provides the least opportunity for micromanagement.
I’ll illustrate with a story of personal growth I witnessed. One team I converted to Scrum failed to deliver one or a few stories in each of its early sprints, and most of those had a common volunteer. He repeatedly chose to work on nonsprint tasks early in the sprint, and the delay in getting his tasks done cascaded throughout the task lists until later ones for other people could not get done by the end of the sprint. Serving as the SM as part of their training, I pointed out the problem without naming names both when the Burndown Chart was lagging early in the sprint, and during the Retros. That didn’t work, so I had two private phone calls with him (the team was virtual). He agreed to “front-load” more, but didn’t do it. Seeing the problem happen again in the fourth sprint, I felt I had to switch to sports-coach mode and call him out during a scrum call. He exploded at me and accused me of micromanaging him. In the next day’s scrum, however, he apologized for his outburst. He admitted he needed to change his attitude and explained, “I guess I’m just used to doing my own thing.” He did change, and the team hit 100% delivery the next sprint.
Having lived in an area with many pharmaceutical and biotechnology companies, I have often heard the concern that somehow Agile is incompatible with products that must pass strict government standards. Maybe people who have only worked in waterfall environments can’t imagine how to meet standards without first writing 400-page specification documents.
I worked with the most regulated “product” there is, in a government facility: nuclear weapons. I’ve also participated in ISO 9001 quality certification efforts. Agile handles regulations just fine. In FuSS, this is where the Agile Liaison role and business requirements come into play. As ALs, those experts who maintain the company’s regulatory or certification compliance participate in the grooming of epics and user stories. By doing so they identify which ones impact certification or must be completed following particular regulations and guidelines. They then ensure relevant information is cited within the body of the epic or story. They also write business-requirement epics and stories to implement work needed to ensure compliance, or to obtain information from teams that is needed for compliance.
I suspect the biggest obstacle is not Agile, or even the willingness of people to shift to AL roles. In fact, most compliance personnel I’ve transitioned were thrilled to get early, regular involvement. However, most existing process documentation written to maintain certification or meet regulatory needs assumes waterfall thinking. Making the shift to Agile includes rewriting those processes to incorporate the role. In practice I have found this to be less of a burden than the prospective ALs thought. For example, ISO and other regimens often come down to, “Do you document your processes and follow them as documented?” I have easily rewritten the process documentation to match reality such that certification was supported, and found auditors nonplussed once they see the updates.
“If something sounds too good to be true, it probably is,” the very old saying goes. Throw in the fact that people assume price equals value, and I understand if you think FuSS can’t possibly be as good as SAFe, LeSS, Nexxus, or any other Agile system you have to pay for in some way—at least the cost of a thick book!
There are several reasons I decided to publish the content as a free hypertext instead of a thick book. (The original document draft came to 430 pages.) My main reason for writing it was to stop having to rewrite the system with each new contract I got as an Agile coach. First, it was a pain to do, and second, I feared I would eventually run out of different ways to say the same thing!
Also, everything I wrote for clients was limited in detail, mostly pages of bullet lists. I provide a lot more background verbally, and wanted to make that material available to refresh users’ memories. Besides providing more value that way, this potentially reduces the amount of coaching I have to do, because people can go back and review what I said.
I could have published a book, but as a former professional writer, I know the vast majority of books provide very little income to their authors. I was going to have a site anyway due to the downloads, and with all the material published on the site instead, I could continuously improve the text. Of course, I could have made it a paid site, but that would have required significant marketing, which I don’t like doing. Also, I am not selling myself as a consultant. As noted elsewhere, I do not believe drop-in (“seagull”) consultants are cost-effective. As long as I have one full-time contract as a coach, I don’t need other work.
Finally, given that I excoriate the Agile Industrial Complex for emphasizing money over the promises of the Agile Revolution (see previous link), it felt hypocritical to charge for my system. When I talked to the manager of my kickboxing gym about my plan, she put it perfectly: My product is free, but I charge for my services.
In companies converting a few teams that already had digital trackers and an initial set of requirements, I have completed the team-level changes described in Full Stack Scrum in as little as a week. Most teams I work with directly take up to four sprints before they start meeting the Agile Performance Standards, although a few have delivered 100% of their stories in their very first sprint! Those were the ones willing to just try what I was saying instead of constantly raising objections. I once watched a high-school robotics team learn to groom stories perfectly in two hours. As students, they had no preconceptions blocking their willingness to learn.
Of course, I’m an experienced Agile coach and can do all the steps from memory instead of reading them from a Web site! So a Scrum Master or Agile Release Manager needs to be patient and understand there is a learning curve for him or her as well as the team. Plus, if the team doesn’t have a requirements set and a tracker, that may add considerable transition time. After those are in place, I recommend allowing six sprints before you start to worry whether a team is catching on.
By similar logic, I tell programs preparing for their first Planning Release, “it will be a train wreck!” Only in one case has a program hit 80% epic acceptance the first time out, and that program had considerable experience with a form of Scrum before I showed up. Plus, I had already instituted the team-level changes fully. Consider the first release a trial run, but if you follow the release planning process as presented on the site, by the second release things will go much smoother.
I’m not sure there’s much point to using Scrum for two people, unless you know the team will be expanding soon. They can just talk, per the Manifesto! Nonetheless, I have known single individuals who ran their working lives in sprints and saw benefits, including a finance professional and an analyst.
On the upper end of size, surveying the Web, I see that most experts seem to recommend between five and nine as the ideal size range. For me this is more proof that Agile matches scientific evidence about teamwork. When I was going through hundreds of studies on small groups to write The SuddenTeams Program, it became clear that the ideal size for any team is probably in the four- to eight-person range. My preferred maximum is 12, and I refuse to call a group larger than 15 a “team.” The psychological dynamics and the management techniques required are shifting from those of a small group to a larger organization at that point.
There is a simple mathematical reason for keeping teams small. Every extra person adds exponentially to the number of pairs of people within the team who must communicate and cooperate at some point. Here is the formula:
where n is the number of people in the group. Thus if there are 5 people in the team:
(5 x 4)/2=
10 pairs of people ( or potential “communication channels”)
A team twice that size, 10 people, has more than four times as many pairs of people: 45. Adding one person to a team of five creates five more communication channels. Each increase means exponentially more:
- Potential discussion time in team meetings.
- Demands on members’ time from other members (due to requests for information or help).
- Potential points at which coordination of work can be delayed as one person waits for another.
- Points at which handoffs of work can fail.
- Opportunities for miscommunication.
If you counter that not everyone on your team needs to talk to the others regularly, I would ask, “Why are they on the same team, then?” They aren’t, really. If members don’t have to interact to deliver their work, they form what some scientists call a “work group.” Task interdependence is a key marker of a true “team.” Without it, trying to improve “teamwork” is a waste of time.
With large teams, furthermore, the number of labor hours you must cover to fill everyone’s capacity during Planning Ceremonies becomes daunting. For a team of 12 in three-week sprints of six-hour days, that means accounting for over 1,000 labor hours each sprint!
I once worked with a team that had 15 people (105 communication channels). Planning Ceremonies for a three-week sprint often ran four hours, about twice as long as those for most of my teams. Had the company split those teams into two as I advised and thus the meetings in half, I think it could have saved a minimum of $1,050 in unnecessary meeting time every three weeks, or around $17,850 a year. And that’s only for the Planning Ceremonies. Grooming sessions were equally tiresome, and keeping scrums to 15 minutes was a challenge almost daily.
Taken together, I recommend you never have a Scrum Team that is larger than 10 people. If another person is coming in, split the team into two full-stack teams, giving each responsibility for a well-defined portion of the overall work.
Trying to serve on more than one Scrum team is, if you’ll forgive the pun, very trying. The biggest reason is the percentage of time that person must spend in meetings. For two-week sprints, a mid-sized, mature team might spend at least a six hours, or 10% of its time, in the various ceremonies. Obviously that means someone on two teams is spending 20% of their working life in meetings—not counting the company’s nonsprint meetings. Add in the fact they have people on two different teams asking them for timely handoffs; have to do task updates in two sections of the tracker (or two paper trackers); and so on, and you will reduce that person’s productivity and job satisfaction further. Plus, often that person is on multiple teams because they have a unique skill set and thus represents a “Won-the-Lottery Syndrome” risk for both teams.
The next problem is that the Scrum Masters for the two teams have to work around the schedule limitations of each individual who is on multiple teams. It is hard enough to find times when one self-contained set of people can meet together for the various Scrum meetings. Now imagine working around all of the times one—or two or three—people are already in another team’s meetings! It becomes, frankly, ridiculous.
Finally, there is the issue of prioritizing time. This individual has promised to help both teams deliver all of the teams’ stories (not just the ones they volunteered for). What happens when both teams need that person in the same time period to help with problems? You are setting up both teams to fail.
The alternative, excusing someone from some subset of each team’s meetings, is also setting up the teams and individual to fail. During those discussions the rest of the team loses the insights of that person, who is probably the only one with a skill set the team needs. The team will have to make decisions that impact that person without their input. This in turn will reduce the quality of those decisions and the person’s commitment to decisions made. Finally, all the benefits attributed to stable teams are reduced by part-time members.
In short, you injure both the individual and each team when you split people. The easiest answer to the problem is cross-training. Leave the technical expert on one team, and have him or her train people on each of the other teams that need the skill set (see “Cross-Training”).
Another, less optimal option is to pull the technical expert off of all Scrum teams and work as an “individual contributor” on which the various teams have dependencies. That person would be responsible for managing time such that he or she only commits to as much work as can be done in each given workweek, and to be aware of each team’s dependencies and sprint needs. As you can guess, this can greatly complicate sprint planning for each team and the achievement of the Agile Performance Standards.
Many Agile coaches believe a team should sit in a single room. The theory is this increases communication and creativity and thus raises team productivity.
Unfortunately, this advice flies in the face of a hundred years of research into workspaces. (I am not exaggerating.) As a teamwork consultant, I looked at many studies or data-driven books on the topic, and concluded there is a good reason research shows that at-home workers are more productive hour-for-hour than those in offices. It’s a matter of control over the environment, though, not of “home” versus “office.” There is overwhelming evidence that most desk workers are less productive as individuals in anything other than a private office or floor-to-ceiling cubicle. The reason is simple: Human brains are hard-wired to notice changes in their environment such as movement and noise. Each phone call or loud conversation of others and each body moving across one’s field of vision steals time and focus from the work at hand. Add in that people have different optimum temperatures for productivity, so at any given room temperature a significant portion of the occupants are too hot or too cold.
Surveys over the decades have shown that a lack of privacy is correlated with lower job satisfaction as well. This in turn tends to increase the rates at which workers quit, and can contribute to communication and work behaviors that weak managers lump under the generic phrase, “bad attitude.”
Thus any gains in collaboration and group productivity the team gets by working in the same room in open workstations are more than wiped out by losses in individual productivity. Far better to allow people as much privacy as the team’s manager is empowered to provide while letting the processes of Scrum create better communication and collaboration. Companies that opt for open floor plans “for better teamwork” are at best ignoring hard data and looking for a “quick fix” to their problems. At worst, their top managers are using claims of higher team productivity as an excuse not to spend the money to provide workers with some portion of the benefits managers get from their private offices. In doing so, they throw away longer-term productivity gains that would pay for the cubicles in a few years, because fewer workers would be needed to get the work done.
In fact, every claim I have read or heard that an open workspace improved teamwork was based on contaminated data. By that I mean, in every case the change was accompanied by process and/or tool changes that could have been the causes instead. There were no direct comparisons between conditions. I found no case study measuring the productivity and job satisfaction of different sets of collocated teams in the same company in which each set changed their workspaces only without also changing their processes, tools, and/or team structures.
This might be why Extreme Programming (XP) came up with the idea of “caves” and “commons,” both personal and team spaces. The concept developed before there were digital trackers, so it made more sense to have a dedicated conference room where the team could leave its paper tracker in place and display handmade burndown charts. With the digital tracker taking away the need for these, a bulletin board in the area where the team sits may suffice. For all the teams I have worked with, even before Agile, a team room was neither possible nor necessary to achieve measurably high performance. Obviously the team needs reliable access to conference rooms where it can comfortably meet together for the hours required for ceremonies and technical meetings. The rest of the time, people need private workspaces to maximize productivity.
The best arrangement I have personally seen was a building with narrow hallways, both sides of which had narrow but deep offices. An entire small team could fit into one short hallway. People would banter and collaborate freely with their doors open, but close them to go “heads down” when they wanted to focus—or get warm! Meanwhile, they used a digital tracker, and the building had plenty of conference rooms such that one could be regularly scheduled for ceremonies. Ad hoc meetings generally fit in someone’s office.
Most of the teams that do not regularly hit 100% delivery after a few sprints face one or several issues, listed here with the relevant sections of the site:
- Failing to fully groom stories to identify dependencies and risks—“Caring for Dependents” and “Projects are a Risky Business.”
- Not thinking through tasks to enough detail—“Take Them to Task.”
- Failing to block stories that are not ready for a sprint—“Blocks to Progress.”
- Underestimating how much time tasks will take—“Estimate the Hours” and “Improve Estimation.”
- Overestimating how much time they have for project work, or not allowing enough time for work that is hard to plan—“Planning for the Unplannable.”
In general, the less self-discipline the team employs in learning this new “sport,” the less likely they are to win at it. Keep the team focused on the issue(s), and during the Retrospectives each sprint, drive members to identify why they are failing to adjust. In particular, do not let yourselves blame external factors. In almost every case, if you are being brutally honest with yourselves, you will find ways you could have anticipated the problems that prevented timely completion.
This happens to everyone in one sprint or another. To provide the most support possible toward meeting the team’s goals, there are several options to try, in this order:
- Ask via e-mail or in a scrum whether anybody on the team needs help with their tasks, or has tasks you can take from them.
Note: Do not start working on a task chosen by someone else without asking first. Among other reasons, they may have started work but forgotten to mark it in the tracker; might really want to do that task; or could be waiting for critical information.
- Start working on a story near the top of the backlog.
Note: Do not pull it officially into the sprint, however.
- Spend some time on longer-term efforts that will help the team, such as:
- Training on or practicing skills that would let you take a wider range of tasks in future sprints.
- Researching tools or techniques the team is considering using.
- Ask your manager if there is nonsprint work you can help with.
If this keeps happening to one or more members of the team, that is a strong indicator the skill sets are out of balance on the team. Often cross-training can fix it, but if not, this situation may be evidence that you need another person of a particular discipline. For example, if software developers are handing off small bits of functionality frequently to experts on other teams, either the developers need to expand their expertise or you need to hire another expert.
In my experience, this situation is rare. I mentioned a study earlier in which 60% of people who went through an Agile transformation at one company preferred Agile, and another 30% were comfortable with it. Humans are social animals, so most of us can adapt to a team environment even if it is not our preferred work situation. My favorite work activity is sitting alone in a library researching scientific findings on teamwork. But it’s hard to make a living at that, so instead I work in multiple teams most of the time!
However, some people are true loners, or at least want to feel fully in charge of their daily fates. Their resistance will become clear when they refuse to follow team processes, or to fully participate in ceremonies, or to share their specialized knowledge such that others can take related tasks. When I run into that kind of person, I am not afraid to recommend the manager find an individual contributor role for them if possible. Despite my belief in the power of empowered teamwork, that doesn’t mean everyone has to be a “team player,” a term I consider badly over-used in business. (Most often it is code for, “Shut up and go along with everybody.”) There may be a place for some individual contributors in any organization. And in larger organizations not committed to Agile, there may be other non-Agile groups where the individual is a better fit.
This will sound harsh, but if none of those spots are available in your organization, it is fair to ask if that person is still in the right company. When the work environment changes to become Agile, each worker has a choice between adapting or becoming ineffective. In the rare latter case, it will be better for both the team and the individual for that person to find a different employer.
Always start from the assumption the person wants to do the sprint work they committed to, but is being prevented from doing so. Most individual performance problems turn out to be process problems. Everyone will have trouble on occasion, but when a pattern develops, I contact the individual and ask:
- Is some manager or peer asking you to do other work?
- Are you getting pulled into last-minute meetings?
- Is your planned nonsprint work taking a lot more time than you expected? In this case, coach them to lower their capacity commitments accordingly, or raise the estimates on their placeholder tasks, depending on how the team is planning for the unplannable.
If these “environmental” problems are not to blame, find out if they need more Scrum training with questions like these:
- Are you having trouble seeing what tasks people are waiting on?
- Are you held up by questions you have about the work that the team did not get answered in grooming?
- Have you considered blocking out time on your calendar for sprint work?
- Could you close your e-mail and chat tools for an hour or two during those times, so you aren’t tempted to multitask?
- Is the team talking you into tasks you don’t really want (or know how to) do?
- Do you feel you must respond to requests for your time instantly?
Often during these chats the real problem will come out, and the solution will be fairly obvious.
In each case the change process is usually a matter of reassurance and education. Offer to meet with the person and their manager to clarify the manager’s expectations about responsiveness versus the priority of sprint work. (People who don’t want to meet with their manager find this motivating enough to change their behaviors!) Others will be helped by knowing their manager thinks it is okay for them to close the chat service or turn off their phones, for example. Most managers are willing to change their thinking about asking for nonsprint work when they understand the impact. Sometimes the employee and manager will agree to reduce the employee’s capacity commitment in the team’s sprints. Though not great for the team, this at least makes predictions more realistic.
Be prepared to repeat the questions and reinforce the lessons, sometimes over months. Ingrained work habits can be hard to change, and all of us have to hear some things over and over in different ways before they sink in. In my experience, almost all team members will adjust their behaviors as needed within three sprints after taking the steps above. After addressing all of these possibilities, occasionally the problem boils down to the team member not wanting to change his or her way of working. See the “member… hates Agile” question and answer above in this case.
Humans consistently underestimate how long something will take. There’s plenty of research to that effect, but surely you have seen directly the impacts of this hard-wired bias. Think of how many times you have heard the question, “Why is it taking so long?” Recall how many deadlines you have seen missed, or how many times you have gotten frustrated waiting on something. In your personal life, how often does any goal take longer than you thought? “Everything takes longer than it should,” I often say. In each of these cases, either the doer or the waiting person or both have underestimated the time required.
Breaking tasks out in greater detail, applying estimates, and re-estimating to-dos is a highly rational way of breaking through that irrational bias, especially when subjected to review by others. Estimation combined with capacity planning is the most reliable way to prevent overcommitment and deliver stories as promised. Plus, to-do hours are the most accurate way to measure progress toward completing the sprint.
Speaking as a certified waterfall project manager, I can tell you that a full waterfall system requires the estimation and logging of hours. That is how waterfall projects track costs. But Scrum offers an advantage to team members. The Scrum approach suggested in this site only has you track labor hours if you need a way to get better at task estimates, and only until you don’t need to.
I liked the concept of story points when I learned about them, and found the planning games used for them fun. In four companies, I taught them and tried to get away from using task-hour estimates. By the fifth, I gave up on points. Maybe they are fine in organizations who do not push for 100% delivery (and give up the attendant benefits of that approach). For those who want the benefits, however, points are simply not as effective as hours.
Psychology and math explain why. Humans are bad at dealing with abstracts. For example, research into adult learning shows that training without follow-up coaching tends not to be effective. It’s one thing to understand a better way of doing things when you’re in a classroom. The challenge is to recognize when a situation has arisen to which that new skill applies in that moment, and instantly figure out how to apply the new skill. As far as I’m concerned, that’s half the reason for having a Scrum Master, to serve as an ongoing coach in “real time” regardless of which Scrum approach you use.
Story points are very abstract, and even experienced Scrum teams new to them struggle with the concept. For new Scrum teams, it can seem a useless addition to grooming time and become a barrier to people making the shift to Agile thinking.
Use of a commonly understood vocabulary is an important aid to conflict-free decision making. Think about how many meetings you have been in where someone asked, “What do you mean by (insert term here)?” No matter how much guidance on estimating points I provided to teams working with them, members would still be applying radically different initial numbers to many stories during planning games a year later. This suggests disagreement on what a “point” means. There is no such disagreement on what an “hour” means. Even on cross-cultural teams, everyone can argue cogently on how many hours something will take.
Regarding longer-term estimation like release capacity, I’ve mentioned before that data from more than 10,000 teams found points only provided a marginally better prediction of productivity versus mere story counts. The analysts decided the increase in precision by using points instead of counts was not worth the mathematical hoops required to compare velocities among teams, because the teams would apply far different point totals to the same amount of work. The story count was always the same, however (“1”).
Another objection raised is that you can have a wide variation in story sizes sprint to sprint or epic to epic. That is, the team might fill up its capacity on five stories in one sprint, yet require eight the next one despite similar capacity numbers.
This is a case where “common sense” does not hold up to the evidence. Over time teams tend to develop a pattern where they create and take into Sprint Plans roughly the same proportion of 13s vs. 8s vs. 5s, for example. They also tend to cluster their point sizes such that the vast majority of stories have one of three numbers. In one team it may be the three mentioned above; on another it might be 8s, 5s, and 3s. Regardless, by not using all numbers of the range, they are not being all that precise anyway.
Furthermore, sprintly variations tend “to average out over time,” as people sometimes volunteer at this point when I am arguing this verbally. Plus, points are no better than counts at accounting for which stories will get blocked or otherwise fail. These facts reinforce the notion in the previous paragraph, that you are not gaining much precision for the extra effort of sizing stories and epics.
The best argument is history: I have repeatedly succeeded at getting teams to high sprint and release predictably using hours and counts instead of points or “tee-shirt sizes.” Capacity Planning using hours also provides benefits to the team points cannot, and doesn’t take any longer to do in mature Scrum teams. So hours estimation is a better use of time than point estimation.
Finally, I have seen managers regularly abuse the concept of story points to fit their waterfall thinking about long-term planning and measurement of team performance. Although they could do the same with story counts, I think the apparent precision provided by applying different numbers to each story is more open to misinterpretation by people without much Scrum experience.
Labor-hour estimates for the same tasks will often be different for different people. During grooming, ask about rough sizing (whether the task will take a day or less, or at most two) based on someone who is experienced with the work. Then worry about the specific hours after a volunteer has chosen the task.
During planning, you might decide to let a junior member of the team tackle it. Besides adjusting the time for key tasks upwards, you’ll also want to add tasks for cross training in that case (see “Cross-Training”).
You don’t have to track labor hours, also called “effort,” under FuSS. Given that it requires some extra effort, can be misused by managers who wrongly equate hours with productivity, and conflicts with the Agile principle that “Working software is the primary measure of progress,” I don’t want you to.
However when teams are struggling with estimation, I have found tracking labor hours by far the most reliable way to improve estimation. Compare your actual hours to your estimates for a few sprints, and I guarantee you will improve. Once you are delivering a certain number of stories each sprint, a consistent velocity, I suggest you drop the mandatory tracking of actual hours and only track to-do hours for the burndown charts. When you are hitting 100% delivery most of the time, you might even be able to drop to-dos and use velocity alone. Try that from the start, though, and I can almost guarantee you will never get there.
I will note, also, that some people choose to keep tracking their individual hours as a way of continuous improvement. I’m fine with that. The better you are at estimating, the easier your project life will be.
 Wheelan 1994; Hackman & Katz 2010.
 Park & DeShon 2010.
 In collocated teams, you usually work in the office or plant. However an Agile organization will give the individual freedom to work at home a portion of their time to the degree possible given the nature of the work.
 Based on a conservative estimate of $70 per hour of average total compensation (benefits included) for those software professionals in 2012; savings of only one hour per Planning Ceremony; and 17 sprints per year.
 Laanti, Salo & Abrahamsson 2011.