Product Backlogs and You

I just received this question from one of my co-workers and, because I get it frequently, I thought I would post both the question and my response to it. She is on a project that has been going for some time now but which was being driven through old/traditional PMI techniques. Because it was failing, as those techniques do about 85% of the time, we recently transitioned them to Scrum. She writes:

One thing that everyone wants to know is "when will we be done with the project" - and that would mean that we go through every story - spec out every task - assign points/owners to each. So I am confused about two things:

1. Where does the team find the time to do this for every post-it on the backlog wall? I am assuming the whole team needs to be involved in this exercise.

2. Points do not translate into time taken. So let's say even if we did do 1, all we would get is points. How do I convert this into "this project will be done by date xx/xx/xxxx".

Any help you can provide will be great.

My response is below:

You're right to be concerned about the size of the task in front of you. It's going to be a bit dicey and time consuming to get things set up, but it will be well worth it.

You are correct that the entire team needs to come together to create estimates in Story Points for every card (User Story or Story Card) on the Product Backlog. While it would be excruciating to break each card down to the task level before estimating, that is thankfully not necessary.

The first thing to remember is that up to 5% of your Sprint length should always be allocated to helping your SPO get better visibility/estimates on the Product Backlog. For people on a one week Sprint, like yourself, that is about 2 hours per week of estimating effort. To do the estimates efficiently, you'll want to subdivide your Product Backlog into three zones.

Zone One needs to be estimated in detail, with negotiations when estimates vary widely and thorough discussions to reach consensus. Zones Two and Three should receive quick/rough estimates where you, as the Scrum Master, may choose to either average the votes or select the high vote from the first ballot. Because Zone Two is slightly more digested than Zone Three, this will provide more accuracy in Zone Two than in Zone Three. Expect the team to protest this behavior but assure them that they will get to re-estimate each card as it moves between Zones and is broken down.

So how does all this result in a date? Once you have a rough estimate on the length of your Product Backlog, you use the team's calculated Velocity to estimate how many Sprints worth of work remain to be achieved. So, for example, suppose you go through this exercise and find that you have 612 Story Points of estimated work on your Product Backlog. If your team's Velocity is 72 Points per Sprint and Sprints are one week long, then you know that you have (612/72=8.5) Sprints worth of work to achieve, or a little over two months. Because the boundaries of the Sprints are all firmly fixed (no sliding or changing begin/end dates!) then you can translate this number into a date.

Now what if 8.5 weeks is too long? The first thing you'll want to do is to be sure that you are only pursuing mandatory work during that time. Remove any unnecessary User Stories from the calculation and re-estimate the delivery date. If it is still too long, see if you can outsource some of the work to another team. If that is not possible, and because Scrum is the only framework ever proven to scale linearly, you can ask them to give you more resources. The trick here is that you have to continue to respect the "7 +/- 2" rule on team size and may have to make multiple Scrum teams.

I hope this helps but let me know if you have further questions.

Yeah, it’s simple. But it sure ain’t easy...

Transitions are hard.

Change is scary.


Uncertainty is... well... uncertain.


Dealing with the human and emotional reactions to change is the hardest part of implementing Scrum effectively. Especially in an established organization where people already have established behaviors, expectations and domains, these changes can feel overwhelming, frustrating, inefficient or, in some extreme cases, even insulting.

"The good of the many outweighs the good of the one," a famous Vulcan said (hey, I made it this far without a Star Trek reference... it was tough!). In general, most of us agree with that most of the time. But in corporations, our ability to apply this bit of wisdom is often limited. Whether based on fear, politics or a loyalty to "the way things have always been", this kind of rigidity coming from the upper echelons of a company usually foretells the end of its growth phase and the beginning of its decline. But, with Scrum specifically, the multiplicity of concerns are generally not from the Executives, who are sold on the ability to achieve hyper productivity. It more frequently comes from people at the mid- to lower-layers of the company.


People who have built their careers around being superheroes are suddenly asked to become team players. Managers are turned into servants -- an easy transition for some, but a very difficult one for those who are more authoritarian. The familiar tools are usually judged inadequate or counter-productive for an effective implementation of Scrum, and that can frustrate the career plans of those who have spent years amassing skills and certifications with those tools. When a company stops communicating in the old language of hours, projects, assignments and the "QA cycle", formerly composed professionals can feel adrift, bored or demoted.


A person's reaction to change depends in large part on their general outlook on life. I was once chatting with a fellow -- sort of an Eeyore kind of guy, if you know what I mean -- about the changes that come with a Scrum adoption. "If nothing changes," I said enthusiastically, "how do you expect anything to ever get better?" He turned to me, completely stone-faced, and said, "I don't expect them to get better. I just don't expect them to get any worse either." It's a fair concern.

When you try new things, the likelihood of failure increases. Suddenly, people are broken out of their established patterns and are asked to engage the company's business in a brand new way. I was recently told by a Manager that, before Scrum, a certain employee had been happy to sit idle in his cube for days on end without uttering a word. Those kind of people don't do very well in an effective Scrum company. Scrum will simultaneously add work to the plates of those who have been coasting while taking away the busy work from those who believed that simply being busy creates value. Being busy is great, but only if you're busy heading in the direction identified by the company -- and most busy-work workers aren't.


But for every naysayer or Eeyore you've got in your company, you'll have 10 people who are enthusiastic, open-minded and embracing the positive changes they see Scrum bring. They're just not usually as vocal as the people who feel that they are suddenly engaged in a fight for their very careers, and that's a shame. Almost all of the employees in an established company have a good and purposeful home under Scrum but many close their ears after the briefest of overviews. The chief blessing of Scrum can also be a curse -- its simplicity.


A description of Scrum comes in twelve bullet points: Three Roles, Three Artifacts, Three Ceremonies and Three Best Practices. But that's just a description. A real understanding of Scrum comes from a deeper study of self-organization, emergent behaviors and human nature. People who scan a book and develop an opinion or an implementation are likely to leave out some of the most fundamentally powerful components of Scrum simply because they are uncomfortable to implement.

There are a few truths that sound blasphemous to most Engineering minds. For example:

• To generate more value, write less code. 
• Multitasking is value embezzlement. 
• Implement at least 80% of your Sprint Backlog each Sprint, but never implement more than 40% of your product requirements in any given Sprint. 

Too many people who start picking and choosing from Scrum's twelve points do so without the basic understanding of why the points were there and how they play into the achievement of hyper productivity. They stand before several methodologies and fuss over items from each like my Grandmother looking at vegetables in a market, picking some and tossing out others. Now if your company makes money and generates value by building a methodology, then more power to you. But if your company's product is other than a methodology, maybe it's time to buy a proven, tested and well exercised methodology off the rack and focus your energies, instead, on building product.

Compromise is not always a virtue -- especially when the compromise is between a few noisy people clinging to the old methodologies, and an energized plurality willing and eager to make the quantum leap.

Backlog-o-Matic

Prioritizing your backlog can be one of the more confusing exercises when your team first attempts to shift toward Scrum. It’s all too easy to wave your hands at it and say, "That’s the Product Owner’s problem, not mine" -- but no matter what your role is on the team, you’ll likely get involved at some point in time so it’s a process worth understanding.

When you properly feed a Product Backlog, it will actually prioritize itself. The problems most of us encounter come from not feeding it correctly. We stick task cards in without estimates. We adopt cards that fail to state business value. Or sometimes we attempt to dictate solutions with the cards we enter. So let’s start from the beginning and see if we can’t all get on the same page.

First, User Stories must state a goal instead of a solution. The reason that Scrum leads companies to hyperproductivity is because it removes the Command & Control model that artificially limits a team’s intelligence and speed to match the intelligence and speed of the Commander. A multiplicity of intelligent people pursuing a clear goal will always yield a quicker and superior result to having a central controller directing multiple workers. So job one is to state the problem, not the solution.

Next, you need to be sure that all work considered by your team has a clear and stated business value. Any work that doesn’t seek to generate value should be discarded as wasteful. Now some people will read that sentence and object that Engineering Initiatives and bug fixes are important, too. I agree. Just keep in mind that some work is an indirect value contribution -- like refactoring a module, for example. At first glance it looks like an expense but the ROI comes in the form of improved performance, increased stability or greater speed and accuracy when modifying that module for future feature support. So even infrastructure work and bug fixes carry Business Values, and they should be clearly stated just as with new feature requests.

So now you’ve got a collection of User Stories that state the problems instead of the solutions, and each has a statement of Business Value attached. You’re almost done. The last missing component is the statement of complexity from Engineering (a.k.a. "the Story Point Estimate"). This will likely lead to a long negotiation between the Product Owner and Engineering, during which they will mutually examine and modify the proposed User Story. Once it passes muster, the User Story can enter the Product Backlog and easily find its place in the queue.

Now there are a few sorting algorithms that you can choose to apply to your properly populated Backlog. You can choose to organize your backlog strictly by financial opportunities, but that may be short-sighted for your longer term goals for the company. You could organize your backlog to pursue a sequence of themes, but you may leave money or business opportunities on the table if you do this blindly. Or you could sort by desirability -- must-have, nice-to-have and optional. Personally, I think you should sort your backlog in each of the three ways and look for overlapping patterns to emerge.

No single method of sorting your backlog is likely to be right 100% of the time. This is why each team needs a dedicated Product Owner who can spend time analyzing the backlog to be sure that the team is heading in the best possible direction from each of the three perspectives. But before there is any hope of success, you must have a Business Value and a Complexity Statement on a card that conveys the problem, not the solution.

The ScrumMaster-Go-Round

I’m not sure why, but there seems to be a significant portion of the population out there who believe that Scrum Master duties should rotate from person to person each Iteration. It’s usually touted as a "share the pain" policy, with some even saying "nobody should have to do that all the time – they’d go mad!"

Scrum Masters are specialized resources in an organization, just like Architects, Developers, QA and Managers. I doubt anyone would think it’s a very good idea to have each team member take a turn as Architect, rotating once per Iteration. They should be equally uncomfortable suggesting that about Scrum Masters, and I’ll tell you why.

Getting a team comfortable with a Scrum Master takes some time. Just like introducing a new sheepdog to a flock (the often-invoked image of Scrum Masters and their charges), it’s difficult in the beginning. Not only will the new Scrum Master fumble and falter initially but the disruptions will ripple through the team and reduce your value contribution until everyone settles into their new surroundings.

A Harvard study reported that more than 3/4 of all project failures are ultimately attributed to personal problems or issues between team members. If your Scrum Master, who is responsible for helping you resolve that issue, is almost always your peer except for one magical Iteration per quarter, odds of success plummet.

Becoming an effective Scrum Master takes more than just running the meetings. It’s about learning the team members, building a trust relationship, establishing paths of communication with the external resources the team utilizes and spending a significant amount of time analyzing and tracking metrics to discover how to tune the team to higher targeted value contributions.

Further, an Engineer doing a "rotation" as Scrum Master will almost certainly fall into the following traps:

1. S/He will not surrender personal contributions to the Iteration, which creates a conflict of interest when the Scrum Master duties interfere with the potential success of the card s/he adopted.
   
2. Not every Engineer on the team will have the respect and authority to adequately facilitate the meetings and correct behaviors on the team during the iteration.
   
3. Someone serving as Scrum Master for only one Iteration every few months will be at the absolute mercy of a Product Owner who holds the post almost permanently. One of the greatest values that the Scrum Master provides to the team is keeping the Product Owner in check.
   
4. Most team members don’t have (or need) a deep grasp of what the Velocity metric is trying to measure. But to act as an effective Scrum Master, they would have to understand that Velocity is the averaged commit achievement against targeted value contribution, and that adopted, found and punted work have to be handled very differently when calculating the team’s actual work capacity so they can guide them toward a safe commitment. Is this really what you want your Engineers thinking about for a whole Sprint?

I could list several more reasons but hopefully you are beginning to see that the role of Scrum Master is a specific and specialized organizational need, not to be equated with whose turn it is to take the trash out. It’s also valuable to note that, while the role of Scrum Master might sound horrific to the well-meaning Executives who suggest a rotation, there are those among us who love the role and will happily perform the duties without complaint. Frankly, though I started my career as a Software Engineer, I think I would rip my own eyeballs out if forced to return to it, even for one week per quarter.

Ultimately, Scrum is about creating a sustainable pace with a reliable outcome. If the team dynamics are in constant flux, the team will never settle into that rhythm that results in hyper-productivity. You might continue to do as well as you had done before trying to use Scrum, but you’ll never do better. 

And isn't doing better the point?

Why not let everyone play to their strengths, individual interests and skills? Please, stop rotating the Scrum Masters! It only makes everyone queasy…

A History Worth Repeating

"Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has." –Margaret Mead (1901-1978)

In the last decades of the 20^th century, some Engineering veterans began to discuss the perils and pitfalls of their industry. As they shared data with one another, they began to see that traditional projects were failing industry-wide more than 80%[i] of the time. Rigidity and expense were increasing even as customers were demanding more flexibility and lower costs. But while most of the industry was failing to deliver in this changing landscape, some teams rose to the challenge and even exceeded expectations. The study of these remarkable teams sparked a cultural wildfire that has been sweeping around the world, increasing productivity, flexibility and accuracy for the last twenty years.

It all began with two simple questions: How does a single organization give rise to both "rock star" and "average" teams? And can average teams be coached toward rock star performance? In order to answer their questions, this group of researchers undertook a series of studies that would evaluate the highest performing Engineering organizations around the world. A few of the more recognizable names among those studied were DuPont, Toyota, Nokia, Intel, iRobot, Borland, IBM and Xerox. The researchers collected and combed over data for years, reaching back in some cases as far as fifty years. Eventually, behavioral and cultural patterns began to emerge for those projects deemed most successful by the sponsoring organizations. The data, interviews and observations also began to suggest a surprisingly short but consistent list – just twelve points long – that defined the roles, ceremonies, artifacts and behaviors shared by these teams. Though deceptively simple in its brevity, and having been confirmed by real world observations, the publication of the twelve point list in 1986[ii] sparked controversy throughout the industry and inspired a flurry of competing studies around the world.

Among the most controversial points suggested by this brief list of best practices was the notable absence of some traditional roles, practices and artifacts. Even the original researchers had taken these for granted as essential when they began the study but there was no denying the evidence. More than just "missing", they found that these roles and artifacts actually shared an inverse relationship to the team's ability to become hyper-productive. Regardless of the product scope or duration, the more present they were on a team, the less likely the team would become hyper-productive. Project Management, Program Management, traditional project tracking tools and the ubiquitous command-and-control structure of most corporations had been either eliminated or distributed across altogether new roles as these teams evolved toward hyper-productivity.

It wasn't immediately clear to the researchers how the organizational needs were being met with these surprising omissions but understanding this would be essential if they were to develop the truly portable set of standards they hoped to describe. So, as Scientists do, they undertook a series of trials to test not only the portability of the list but to simultaneously test the necessity of each of the points. Could the list be reduced to just nine points? Were six sufficient? To find out, the researchers approached several organizations that were using traditional methodologies and, showing them the data they had collected, convinced them to participate in the experimental application of these best practices to their teams.

The first trial included only teams with an established reputation as reliable producers. From their ranks, a few were defined as control teams that would continue business as usual. The largest subset would be asked to apply varying subsets of the twelve point list while only a few were asked to strictly adhere to all twelve best practices. At the end of the trial, the results were even more astonishing than the researchers had hoped.

Not surprisingly, the teams who continued business as usual had their normal rate of value contribution. The teams who had used subsets of the twelve point list had maintained or only slightly improved their productivity. But the teams who strictly applied all twelve points were found to be, on average, 240% more productive[iii] than they had been just six months before. What's more, employee turn-over had plummeted, customer satisfaction had risen dramatically and employees noted a remarkable improvement in corporate culture for those organizations that complied fully.

In the intervening twenty years since the first studies were conducted, thousands of organizations around the world have adopted the twelve rules and built additional best practices on top of them. Some of these organizations are now achieving five to ten times the industry standard in productivity, while hybrid models and traditional methodologies top out at their original level of productivity.

The researchers, by the way, included Deming, Takeuchi, Nonaka, Ogannaike, Beck and, of course, Jeff Sutherland and Ken Schwaber. This set of best practices distilled from their collective research was first published in 1986 by Takeuchi and Nonaka in a Harvard Business Journal article titled "The New New Product Development Game", wherein they were first referred to collectively as Scrum.

---

[i] Using traditional Project Management methodologies and artifacts, projects of one million lines of code or more fail to meet expectations and customer needs between 70-85% of the time. See PA Consulting Group, 85% of IT Projects FailStandish Group Report on www.SDTimes.com. and the

[ii] The New New Product Development Game, Harvard Business Review, January 1, 1986, Hirotaka Takeuchi, Ikujiro Nonaka.

[iii] See the Softhouse paper, Scrum in Large Organizations