Traditional Estimation FunnelMicrosoft Story Point accuracy
Story points give more accurate estimates, they drastically reduce planning time, they more accurately predict release dates, and they help teams improve performance. Hours give worse estimates, introduce large amounts of waste into the system, handicap the Product Owner's release planning, and confuse the team about what process improvements really worked.

Interesting new research has become available. The Standish Group has updated their findings on project success rates based on analysis of the last decade of data with tens of thousands of data points. In addition, Microsoft has new research findings showing that agile estimation is astoundingly more accurate than traditional project estimation. See:

Scrum + Engineering Practices:  Experiences of Three Microsoft Teams
Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan
IEEE Best Industry Paper award winner

Many people who have managed projects with hours have a hard time understanding why story points are better. They have failed to understand some fundamental data that has been published for over 60 years in the industry literature as well as the latest research.

First, let's look at the latest data on project failures. Failure rates are increasing for IT projects during the current disruption of the global financial system. The latest Standish group analysis shows that agile projects have three times the success rate of traditional projects. Jim Johnson now recommends agile practice be used universally on all projects.


In fact the latest Forrester Group research shows that:
Common Project Management Metrics Doom IT Departments to Failure

The venture capitalists I work with say they have never seen a correct GANTT chart in a board meeting. When they dig down into the problem they say none of their management teams knew the velocity of their teams before they implemented Scrum. Not knowing the velocity of production of the teams is the root cause of 100% failure of release plans to be accurate in their board meetings.

The stability of a user story is critical for planning. A three point story today is three points next year and is a measurable part of the product release for a Product Owner. The hours to do a story depend on who is doing it and what day that person is doing it. This changes every day. The GANTT chart assumes a fixed number of hours for some fictitious person (who often is not the person to implement) and assumes fixed dependencies (which are always changing). A study of 80 multimillion dollar projects at GSI Commerce (now owned by eBay) showed that the best experts in the company were totally incapable of estimating how much time a project would take by the people who actually implemented it.

You would think these data would cause people to change their behavior but many companies seem to prefer to continue to fail and be acquired or go bankrupt rather than improve their project management techniques.

Rand Corporation research in the 1940's showed clearly that humans are not good at estimating hours and practical experience repeatedly confirms the research. The recommended the Delphi approach to estimation which was adopted in software development as the Wide Band Delphi technique. The same technique is now embedded in the practice called Planning Poker for agile teams.

The management metric for project delivery needs to be a unit of production. Production is the precondition to revenue and companies say they are in business to grow revenue and margins (even though in project planning they often do the opposite). At least a venture capital group is clear that it is all about the money and money comes from velocity of production combined with quality of the product. Hours are expense and should be reduced or eliminated whenever possible.

The best data on individual developer performance comes from Yale University and has been reported previously on this blog. The best developer on a project takes one hour to complete a task while the worst developer takes 10 hours (within a project) or 25 hours (across projects). For teams the difference is an order of magnitude greater. Larry Putnam's published data show that an hour for the most productive team turns into 2000 hours for the least productive team.

Hours completed tell the Product Owner nothing about how many features he can ship and when he can ship them.

The important metric is the number of story points the team can deliver per unit of calendar time. The points per sprint is the velocity. Therefore we estimate everything in points for the Product Owner so that he create a release roadmap based on team velocity and adjust the plan if velocity changes.

The way we do story point estimation gives better estimates than hourly estimates as they are more accurate and have less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80% allowing teams to do more estimation and tracking than a typical waterfall team. A telecom company noticed that estimated story points with planning poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

For a complete break down on the points vs. hours debate see Scrum Inc.'s webinar on the topic. 

In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. One large company’s confused finance department expenses all agile software development and capitalizes waterfall development; projects in this company that go agile see their headcounts cut by 50%. This discourages projects from going agile.Scrum’s production experiment framework can align well with the principles of financial reporting. In this article, the author explains the basics of capitalization and expensing, and offers a financial framework for capitalizing agile projects that can be understood by both accountants and agile teams.Software development is an investment in the long-term future. Some software development projects are not long-term investments; it depends on whether the software remains an asset. Agilists should learn proper capitalization and teach their colleagues. Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development correctly.Companies can gain tax advantages by capitalizing software development; by deferring costs they typically offset more taxable revenue and gain more interest income.Corporate agilists need to help finance departments capitalize agile software development properly. ScrumMasters and agile department heads who understand capitalization and depreciation can generate millions in tax savings. Responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.Because recommended accounting practices ignore Agile, the article discusses how to classify costs as capital or operational expenses and gives guidance on how to make the transition from waterfall to Agile in a way that pleases management, accountants and auditors.Making the case for agile capitalization will reduce your company’s tax burden, increase available funds for engineers, and make your auditors happy.You can read the article by clicking on this link: Agile Capitalization--  Vince Mills (Guest Blogger)

Next weekend the sponsor AngleHack and two student groups at UCLA are throwing a huge hackathon. LAHacks will bring together students and alumni from Southern California’s premier technical schools in hopes of fostering a more cohesive start-up community. It seems that So Cal is struggling to create the same kind of start-up magic that Boston, New York City, and the San Francisco Bay area have achieved. Hackathons are becoming more popular and are a Scrum Pattern for good reason. First, they bring people together in a creative and voluntary environment. This encourages people to bond over activities of their choice, helping team members to form stable relationships, which can lead to better team performance and collaboration.
Second, they produce interesting results.  Facebook has been throwing hackathons since 2007. These all-night coding sessions have produced many valuable features for the social media giant including the Like Button, Timeline and Chat.
Third, if used strategically, Hackathons can slow development down a bit, allowing the organization to deal with constraints in other divisions.
But most importantly, they help developers merge their personal interests with their company’s financial interest. Hackathons give workers the opportunity to have a meaningful relationship with their employer by giving them the autonomy to master features and products that they enjoy while creating value for their company.  Research shows again and again that mastery, autonomy and contributing to a community motivates people much more than higher salaries. Hackathons allow workers to help their company and colleagues, plus they aid in recruiting and retaining a motivated workforce.
Scrum Inc. recommends that companies throw hackathons regularly to free people up to be more creative and interactive. The value of hackathons is hard to quantify but one quick look at Google, which allows their employees to work on personal projects 20% of the time shows that when a company emphasizes creativity, awesome things happen.
-- Joel Riddle

There has been a lot of debate within the business world about the merits of time sheets. Some think tracking hours is an important metric while others feel that they are a waste of time. In the Scrum community there is a similar debate: should the team use points or hours when estimating backlog items?
Scrum Inc. recommends using points because hours are problematic on a number of levels. One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output. We use a variety of examples to illustrate this, but two recent news headlines drive the points home, so to speak.
The first story surfaced several weeks ago and involves the big law firm, DLA Piper. In an effort to collect fees, the firm sued a client. The client refuted the billing. During the ensuing discovery process a number of incriminating e-mails surfaced revealed the lawyers on the project overstaffed and had the team performing gratuitous tasks:
“Now Vince has random people working full time on random research projects in standard ‘churn that bill, baby!’ mode... That bill shall know no limits.”
The second example involves healthcare. This week a case study released in The Journal of the American Medical Association showed how medical errors actually increased one hospital group’s bottom line. A mistake like forgetting to remove a gauze pad from a patient during surgery results in further interventions and longer hospital stays, forcing insurers to cover costs created by the hospital’s own mistakes.
Much of the outrage involving these stories focuses on ethical lapses. Let’s not forget bloating time sheets is not only is it unethical, it is poor business.
If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill. The business value is in serving the client’s needs, not in wasteful or fabricated services. For the hospital group business value is derived from healing people and not from long hospital stays and unnecessary surgeries. This is why many efforts to reign in healthcare costs focus on quality of outcome rather than quantity of care given.
Both industries have business models that measure input (billable hours or number of services provided) rather than outcome and both professions are currently in crisis. Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.
Let’s not forget that time is finite, another problem with estimating in hours. After all, there is a reason lawyers and doctors sometimes work upwards of 100 hours a week. If their business models incentivized quality of outcome, doctors and lawyers could simply improve their efficiency, make the same amount of money working a lot less.
Work less! Estimate in points.
Learn more about how using Points can vastly improve your Scrum in our April Webinar.


-- Joel Riddle

I’ve been reading Viktor Mayer-Schoenberger and Kenneth Cukier’s stimulating new book Big Data: A Revolution That Will Transform How We Live, Work and Think. The premise of the book is, now that civilization has the tools to both collect and analyze huge amounts data, correlation is far more telling than causality. Meaning, that when dealing with billions of data point rather than hundreds, knowing the what, rather than why is good enough.
One example the authors use frequently is how Google was able to comb its massive trove of search queries on common flu symptoms to discover where the 2009 H1N1 flu epidemic was spreading.
The CDC was doing the same thing using traditional sampling techniques. Google’s method was more accurate and in real-time (two weeks ahead of the CDC survey,) a huge advantage in controlling the outbreak. Thanks to Google, the CDC learned thewhat (ironically the where in this case) but not the why (which H1N1 carrier was the vector.) And that was good enough to help stem the spread of the virus.
Despite the messiness of Google’s data, it was far more effective because of its size. Big data analysis was made possible by easy access to Google’s search engine (3 billion searches a day,) large servers to store the information and clever algorithms to sort the data into something meaningful.
A corner stone of Scrum is its ability to measure work output i.e. Velocity. As the authors ofBig Data point out, much of human knowledge is based on the ability to measure a given phenomenon. Once we can measure it, we can start to manipulate the input and determine if we’ve improved something by the resulting output. (Doing this again and again is continuous improvement, the impetus of Scrum.)
Because Scrum has made work measureable in more accurate ways than ever before, we could digitalize the metrics and create a huge searchable data set. For example, Microsoft has had over 3000 Scrum team members for several years. Imagine the possible insights if all that data were pooled and subjected to smart algorithms. Or, if companies that build and maintain virtual Scrum boards started storing all Sprint data from every client using their tools.
Perhaps we could see that adding a new team member results in a temporary drop in productivity but an overall long-term gain. Managers could hold off adding a team member before a key product release. Or perhaps the data might show that teams were more productive when working only 6 hours a day instead of eight. The possibilities are really exciting.
By using big data techniques, no longer would thought leaders in the Scrum community have to conduct case studies or theorize about what might create a process improvement. Nor would Scrum Masters need to tweak their process and wait until the end of the Sprint to see what the results were. Rather, they could simply query the data set and get an answer immediately. 
Big Data is a big deal. 
 -- Joel Riddle

This month, Scrum Inc.’s monthly webinar focuses on fundamentals and correcting bad Scrum habits. While a majority of us feel like we get the basics right, Scrum Inc. surveys and independent polls find that while most Teams understand the basics, many skip at least one key practice.
Most commonly, respondents indicate that their teams don’t calculate Velocity. Without Velocity, there is no way to measure improvement, have transparency and visibility into your process or properly plan a Sprint or a release.
How it Works
Break work into small tasks. Give these tasks, called User Stories, a point value by estimating their relative sizes. (Relative size is important because studies show that humans are incredibly poor at estimating jobs in hours.
During Sprint Planning, the Scrum Master plays dealer in a game of planning poker. The Scrum Master starts the game by taking a User Story and having all members of Team chose a card with a number they believe relates the relative size of the task. The Scrum Master counts to three and all Team members reveal their cards simultaneously. The Team members with the lowest and highest cards debate the reasons for their choices and then the team plays another round. The process repeats until a consensus is reached. Continue the game until the all tasks have a point value.  
During the Sprint, as each task is moved to done, the Scrum Master can plot the points over the length of the Sprint. At the end of the Sprint all the points added together is the Velocity.
As the Team completes more and more Sprints, the Scrum Master can compare how much the Team has improved. Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint.
Remember, just because the team has gotten better at implementing any given story, the point value you should remain the same. If the Team starts to estimate stories at lower values because they have incurred substantially more experience and the stories seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work. 
Teams shouldn’t obsess about how many points something is worth. Estimating points is just an exercise to help quickly evaluate relative effort. The important thing is that you are consistent and that the entire team has a common understanding of their system for sizing.
Whether you are new to Scrum or a long time practitioner, getting the basics right will definitely improve your Velocity. On Tuesday, March 26th we will be exploring Velocity, Retrospectives, Backlog Grooming and the rest of the Scrum Fundamentals. Please join us.
-- Joel Riddle & Christine Hegarty

IROBOT's Genghis Khan now in the Smithsonian

I joined Easel Corporation in 1993 as VP of Object Technology after spending 4 years as President of Object Databases, a startup surrounded by the MIT campus in a building which housed some of the first successful AI companies.

My mind was steeped in artificial intelligence, neural networks, and artificial life. If you read some of the resources on Luis Rocha's page on Evolutionary Sytems and Artificial Life you can generate the same mind set.

I leased some of my space to a robotics professor at MIT, Rodney Brooks, for a company now know as IROBOT Corporation. Brooks was promoting his subsumption architecture where a bunch of independent dumb things were harnessed together so that feedback interactions made them smart, and sensors allowed them to use reality as an external database, rather than having an internal datastore.

Prof. Brooks viewed the old AI model of trying to create an internal model of reality and computing off that simulation as a failed AI strategy that had never worked and would never work. You cannot make a plan of reality because there are too many datapoints, too many interactions, and too many unforseen side effects. This is most obviously true when you launch an autonomous robot into an unknown environment.

The woman I believe will one day be known as the primieval robot mother by future intelligent robots was also working in my offices giving these robots what looked like emotional behavior. Conflicting lower level goals were harnessed to produce higher goal seeking behavior. The robots were running in and around my desk during my daily work. I asked IROBOT to bring Ghenghis Khan to an adult education course that I was running with my wife (the minister of a local Unitarian Church) where they laid the robot on the floor with eight or more dangling legs flopping loosely. Each leg segment had a microprocessor and their were multiple processors on its spine and so forth. They inserted a blank neural network chip into a side panel and turned it on.

The robot begain flailing like a infant, then started wobbling and rolling upright, staggered until it could move forward, and then walked drunkenly across the room like a toddler. It was so humanlike in its response that it evoked the "Oh, isn't it cute!" response in all the women in the room. We had just watched the first robot learn how to walk.

That demo forever changed the way the people in that room thought about robots, people, and life even though most of them knew little about software or computers.

This concept of a harness to help coordinate independent processors via feedback loops, while having the feedback be reality-based from real data coming from the environment is central to human groups achieving higher level behavior than any individual can achieve on their own. Maximizing communication of essential information between group members actually powers up this higher level behavior.

Around the same time, a paper by Christopher Langdon was published out of the Santa Fe Insitute mathematically demonstrating that evolution proceeds most quickly as a system is made flexible to the edge of chaos. This demonstrated that confusion and struggle was essential to emerging peak performance (of people, or software architectures, both of which are journeys though an evolutionary design space). It also showed clearly why waterfall projects slow down as you add people, methodologies, roles, meetings, and reports.

On this fertile ground, the Takeuchi and Nonaka paper in the Harvard Business Review provided a name, a metaphor, and a proof point for product development, the Coplien paper on the Borland Quattro Product kicked the team into daily meetings, and daily meetings combined with time boxing and reality based input (real software that works) started the process working. The team kicked into a hyperproductive state in March of 1994 (only after daily meetings started), and Scrum was born.

There was an interesting radio piece on American Public Media’s Market Place the other day. Host Kai Ryssdal talked with Stephan J. Dubnar of Freakonomics fame about what the latest academic research on feedback tells us. 
Here’s how it breaks down: to get people to commit, positive feedback is shown to be really helpful. So if you have a new Team member, the Team and the Scrum Master should see substantial improvement in that new member’s commitment by focusing comments on what that team member is doing well.
However, once that Team member is fully on board, a Scrum Master would see diminishing returns from continued positive feedback. To get increased performance at this point, critical feedback is the only game in town. Basically, if you want improvement out of a committed Team, you have to point out what they are doing wrong and help them find a better way to complete their tasks.
The other interesting finding is that the more expertise someone has, the more they tend to filter out positive feedback. So if you have a great coder with 20 years experience, giving him or her props isn’t going to do much.
You can read all the research the story was based on here.
-- Joel Riddle

Now in its 47th year, the Hawaii International Conference on System Sciences (HICSS) is one of the longest-standing continuously running scientific conferences. This conference brings together researchers in an aloha-friendly atmosphere conducive to free exchange of scientific ideas. The next conference will be held January 6 through 9, 2014 at the Hilton Waikoloa Village on the Big Island. 
If you've been doing innovative work or research on agile methods, here's an opportunity to present and collaborate with like-minded agilists, in a tropical setting. Submit your paper to the HICSS 2014 Agile and Lean Organizations minitrack by June 15, 2013.
Agile development methods promote iterative product releases and drive risk-reduction earlier in product development. Characteristics include: cross-functional teams, automated testing, continuous builds and deployment, pair-programming, bias-avoiding estimation, process improvement and short feedback loops. Advocates claim agile development produces greater staff resiliency, better release forecasting, fewer product failures and more sustainable work pace.
Lean product management methods test hypotheses and rapidly adapt to discoveries. Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction and customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient use of development staff.
In this minitrack, we seek research papers and experience reports that describe how agile development and lean product management interact with organizations, their structures, cultures and products:

• What evidence-based guidance can we provide to leaders to help motivate, create and sustain agile/lean organizations? How do agile development and lean product management interact with product groups, departments, companies?
• How do organizations restructure to support these philosophies and when they do not restructure, what happens?
• What cultural requirements and/or training are needed for companies to maintain agile behavior?
• How do organizations structure coaching, training, mentoring, Scrum Mastering?
• How do they identify metrics, measure improvement, and improve?
• How do markets respond to rapid iterations and end-user experimentation?"

Submission guidelines are available here. If you are interested in reviewing articles for the Agile and Lean Organizations mini-track, please contact Dan Greening at dan@senexrex.com
We're looking forward to seeing your submission, and seeing you at HICSS 2014 on the Big Island of Hawaii!

Mini-track chair Dan Greening is the Managing Partner of Senex Rex, a management and training firm. He helps international enterprises plan and manage sustainable agile transformations. He currently manages agile coaching at a large international software company. He previously led transformations at Citrix Online and Overstock.com. He developed portfolio management and finance strategies for agile projects. In previous lives, he was Principal Investigator for 3 NSF SBIR grants, created three product startups, worked at IBM Research, and delivered newspapers in the rural Midwest.

The Certified Scrum Master class attendees were off and running on a self-organization exercise. The drill was simple: plan, build, and test as many paper airplanes as you can in 3 minutes.
I was busily preparing for the next class module when I gradually became aware of what was transpiring:  “Twenty-four”, “Twenty-five”, “Twenty-six”… like the coxswain of an Olympic crew team, the Product Owner called out the production count.  With heartbeat regularity, every two seconds another paper airplane floated gracefully across the room, nosed into the exact same spot on the projection screen and settled gently into a tidy pile on the floor.
Their product design? Standard. Their manufacturing process? Pretty conventional. But for 180 seconds in Munich, aptly-named “Team Front” achieved the perfect state of Flow that we wish for all our Scrum teams.
Congratulations to “Team Front” on their new world record!  Pictured (from left to right) are: Oliver Heerdegen, Chris Holland, Todor Ganebovsky, Karla Korb, Thomas Bohne, Katrin Sulzbacher, Norbert Toth-Gati, and Klaus-Rüdiger Hase.Flow is that transcendent state where, with very little explicit communication, team members mesh into perfect formation, each contributing equally and to their utmost toward a singularly shared goal. Eight individuals who had been complete strangers only hours before were working in complete unison as if they had trained together for years.
When the clock stopped, the tidy pile of planes had reached 32…shattering the previous Scrum record of 28.
We spend so much of our time in the Scrum community focused on the nuances of running Scrum: How do I manage teams across multiple locations? How do I balance a sustainable pace with Velocity? But sometimes it is important to take a step back and just appreciate the simple joy of achieving Flow.

-- Alex Brown

Wanna take a crack at breaking the record?  Click here to take course with Jeff. 

New York Times columnist and author Bruce Feiler has just published a new book titled: The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More.  The secret it turns out is applying agile development to your household. 
Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.
Scrum: savior of the modern American family? Watch and decide for yourself. 




You can listen to an NPR review and an interview with Bruce Feiler here and here.
Wanna learn more about Agile and childhood?  Click here for Scrum in schools.
-- Joel Riddle

By Joel Riddle
Scrum is exploding across the industry according to the latest annual State of Agile Survey. Yesterday I talked to Robert Holler, CEO of VersionOne, a maker of agile tools and the sponsor of the survey. He believes the most dramatic number is a 14% increase in people planning to implement agile projects in the future. That forward-looking metric coincides with an increase in the number of companies scaling Scrum (a 15 point up-tick.) Why the bump?



Holler attributes this increase to a decade of compelling evidence. Scrum has consistently shown to mitigate risk, accelerate time to market and effectively manage change, and the message has gotten out. Go agile, or go under.
Given the typical lifetime adoption cycle of new technologies, Holler predicts this year and next will be a tipping point for agile methodologies. In another decade, agile will be completely mainstream.
What’s Your Impediment?
According to the survey, Scrum Masters should be spending a lot of time mentoring Product Owners (POs) and executives. Of the over four thousand respondents only one percent found POs to be Scrum savvy. Executives faired slightly better with a whopping two percent. (Find out why managers need Scrum in our webinar.)
Not a big surprise. At Scrum Inc., we consistently see POs struggling to grasp what the customer really wants and translating that vision into a product backlog. The PO needs to understand the business value of multiple product features; meet customers’ unknown needs and prioritize the work in order to maximize return on investment (ROI). Those skills are hard to find in one person and even harder to execute. POs can be a real lynch pin in Scrum. A company that doesn’t value its POs isn’t going to get the most out of agile.
Who’s the Boss?
Executives get a bad wrap, and no doubt many in the C-suite may not appreciate the self-organizing nature of Scrum. However, given the strong up-tick in companies adopting and scaling Scrum and the recent emergence of management metrics in the Scrum community, executives seem to have caught on. The survey found that executive buy-in is the number one factor to successful agile implementation.
We are the World
The best news for Scrum Inc. is that 72% of all agile practitioners use Scrum or a Scrum variant. Basically, if you are adopting an agile method and want to have a well trained and knowledge staff, go Scrum.
View the cool survey info graphic here.

Recently during a leadership workshop an engineering manager complained that his Scrum teams deliver the product and that it was not what the customer wanted. He thought this was a problem with Scrum.
I pointed out that the Product Owner determines what is DONE at the end of a sprint and if it is not what the customer wants, the Product Owner should declare it NOT DONE. I suggested he might have a Product Owner problem. Scrum doesn't magically make your problems go away, it makes them clear and you know immediately where to look for responsibility.

The engineering manager confessed that they had underinvested in the Product Owner function. The Product Owners are not fully dedicated and are not doing the job. It only took about 5 seconds to diagnose the problems with his Scrum.

The majority of Scrum teams worldwide (and I survey multiple times every month in multiple countries) do not have good Product Backlog Items entering the sprint. In addition to cutting velocity at least in half (a minimum loss of about $75K per month per team), it leads to the customer not getting what they want. At OpenView Venture Partners we think we can hire a new manager and a new Product Owner for $75K a month, but I digress ...

An adequate Product Owner needs to meet these minimal requirements:

1. Knowledgeability
2. Availability
3. Decidability
4. Accountability

Knowledgeability

If the Product Owner does not know the market, the customer, the product, and the competition, the team will lose confidence in their leadership. This will lead to slow down and disagreement over priorities. It is not possible for a new Product Owner to know everything. They need help from management and the team to ramp up their capability. This needs to be built into their job description.

Availability

The best Chief Product Owner is often a business leader (like Steve Jobs). The Product Owner spends half the time working with the customer and the market and the other half working closely with the team. If the business leader has to be part-time, she or he needs a full-time Product Owner to do the day-to-day work. Failing to do this will lead to problems like the one described above. The customer will not like the result, and more work will need to be done. It is cheaper to hire a Product Owner than deal with the damage later.

Decidability

The Product Owner owns the final decision on the ordering of the Product Backlog. Failure to do this will cause priority conflicts and cut team velocity in half. It is cheaper to hire a new Product Owner than to let this happen.

This means the Product Owner needs the confidence of the stakeholders (and the team). If they don't have it, they can't do the job.

Accountability

The Product Owner owns the business plan and is accountable for driving revenue (or whatever value your organization is producing). It is not helpful for a hyperproductive team to deliver many features if the revenue per point is minimal. The Product Owner should be measured on revenue per point and how much the revenue per point is increasing over time.

The Scrum Inc. Product Owner regularly monitors metrics like revenue per point to better order the Product Backlog.
Very few Product Owners know their revenue per point. For this reason, at Scrum Inc. we have developed a management dashboard that shows sprint to sprint revenue per point. Just as the Scrum Master needs to know velocity sprint to sprint, the Product Owner needs to know revenue sprint to sprint. We will hold a webinar on this topic in February with a demo of our management dashboard.

Meanwhile, I strongly encourage all organizations with Product Owner issues to send their key people to our Certified Product Owner workshops in Boston at our venture group headquarters. At a minimum you might save $75K per team per month. The upside revenue would likely be much more than that.

It’s important for Scrum Teams to re-evaluate their practices from time-to-time. Based on results from our online Self-Assessment, we know most of you are adhering to best practices and excelling.

Many teams do almost everything except for ‘that one thing.’ Leaving even one basic scrum principle out of the Team’s practice has a ripple effect on overall performance. That’s why this month we are getting back to basics!

METRICS

Know Your Velocity! Despite being the most fundamental metric, about half of all teams don’t know their Velocity. Without it, showing improvements to management is difficult and approximating a release date is impossible. Estimate your stories, keep a record of how many points you complete each sprint, and get your Velocity.

Use Points, not Hours. Because measuring productivity in hours is so imbedded in our work culture, lots of organizations think it makes sense. It doesn’t. Humans are very bad at measuring things in time. If you are using hours, your Velocity is probably skewed.

RITUALS

The big snag seems to be the Retrospective. Retrospectives can be hard because they reveal uncomfortable truths. Team members don’t want to identify key impediments because they are worried about offending someone. As a result, the one thing that can improve your next Sprint is never identified. Be honest because continuous improvement is the point. Learn more about Retrospectives here.

ROLES

Scrum Masters: remember you own the process. Your relationship with the team involves both support and rigor. Be supportive by removing impediments but be rigorous in your fundamentals. Hold Daily Stand-Up Meetings to 15 minutes, make sure the top priority is being worked on, and that things are moving to ‘done’.  Be both empathetic and disciplined and remember: put the responsibility back on the Team.

The importance of PRODUCT OWNERS can’t be overstated. They represent the needs of the customer and communicate the vision to the Team and management. Product Owners must keep management involved or they will have difficulty translating leadership’s vision into business value for the customer, and well-prioritized and defined tasks for the team.

Product Owners, remember the responsibility of the project is yours.  Make sure to talk regularly to team about the relative business value of the epics and stories. Engage your team in grooming the backlog and helping you clarify stories so that they include rigorous Definitions of Done. This will increase Velocity! (So will avoiding Product Owner common pitfalls!)

SHU-HA-RI

Scrum is based on the principal of Inspect and Adapt. If you are just getting started or are having a tough time showing improvement, get back to basics (Shu). Only then start tweaking Scrum so it works for your Team (Ha). Eventually some teams may reach Hyper-Productivity (Ri). Which state are you in?

Scrum Co-founder Dr. Jeff Sutherland will address these and other issues in his upcoming Webinar: Scrum Fundamentals: Back to basics. Sign-up here.

There was a really interesting Op-Ed in Sunday’s New York Times by Tony Schwartz at The Energy Project. As any good Scrum Master knows, finding a sustainable pace for the team is incredibly important to increasing velocity.
At Scrum Inc., we talk about avoiding Muri aka STRESS because when people are stressed they do poor work. (Last year, Jeff wrote a blog postabout how eliminating overtime at his Venture Capital group increased Velocityby 160%.) We recommend that Teammembers don't work more than eight-hour days and that Scrum Masters avoid death marches. This isn't just out of kindness and respect for Team; it's because people get more work done if they aren't stressed out.
Swartz sites a number of studies:
Spending more hours at work often leads to less time for sleep and insufficient sleep takes a substantial toll on performance. In a study of nearly 400 employees, published last year, researchers found that sleeping too little — defined as less than six hours each night — was one of the best predictors of on-the-job burn-out. A recent Harvard study estimated that sleep deprivation costs American companies $63.2 billion a year in lost productivity . . . In the 1950s, the researchers William Dement and Nathaniel Kleitman discovered that we sleep in cycles of roughly 90 minutes, moving from light to deep sleep and back out again. They named this pattern the Basic-Rest Activity Cycle or BRAC. A decade later, Professor Kleitman discovered that this cycle recapitulates itself during our waking lives.The difference is that during the day we move from a state of alertness progressively into physiological fatigue approximately every 90 minutes. Our bodies regularly tell us to take a break, but we often override these signals and instead stoke ourselves up with caffeine, sugar and our own emergency reserves — the stress hormones adrenaline, noradrenaline and cortisol.Working in 90-minute intervals turns out to be a prescription for maximizing productivity. Professor K. Anders Ericsson and his colleagues at Florida State University have studied elite performers, including musicians, athletes, actors and chess players. In each of these fields, Dr. Ericsson found that the best performers typically practice in uninterrupted sessions that last no more than 90 minutes. They begin in the morning, take a break between sessions, and rarely work for more than four and a half hours in any given day.
Taichi Ohno, the father of the Toyota Production System, referred to stress from overwork as unreasonableness. Check out Ohno’s other stress impediments at ScrumLaband read Schwarz’s entire Op-Ed here.
- Joel Riddle

In the years since the first paper on metrics for hyperproductive teams, I have been thinking about new ways to measure high-performing teams.  Tune in to the webinar "Hyperproductive Metrics" for the latest metrics to guide teams on the path to hyperproductivity.
SCRUM METRICS FOR HYPERPRODUCTIVE TEAMS: HOW THEY FLY LIKE FIGHTER AIRCRAFTJeff Sutherland and Scott DowneyAgile 2010 Experience Report
Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in two ways. They have engines that produce velocity—alignment of the team, and team spirit. And they carefully measures aspects of performance to make slight adjustments in flight. Failing to constantly adjust the flight of the team can result in a hyperproductive crash into waterfall performance.
One hour discussion of a comprehensive, yet minimal set of team metrics used in an environment where hyperproductive teams are the norm, along with an Excel spreadsheet that can be used by any Scrum team to improve performance. Velocity, story completion by priority, work in progress, story acceptance rate by product owner, unplanned work, and trending accuracy of estimates all appear to be essential to determine the altitude, velocity, angle of attack, and attitude of a hyperproductive team. Slight adjustment of these parameters on a daily basis keeps the team on target. Half hour questions and discussion on using the Excel spreadsheet to improve team performance.
Download Scott Downey's Excel Spreadsheet for your Scrum team.