content top

Calculating Value

Calculating Value

Calculating business value effectively and using that insight to prioritize the Product Backlog is one of the most important things an organization can do to drive higher profits and achieve a competitive advantage using Scrum. This is because the Scrum framework helps you to deliver product features independently, allowing you to focus on delivering high value functionality first. Time and again, we see that 80% of a product’s value resides in roughly 20% of its features and that 65% of all features are never or rarely used. By using business value as the lens to order the Product Backlog, the Product Owner can get these features into customer’s hands faster, receive feedback, and maybe discover new high-value features. However, too often it is also one of the Scrum practices that gets glossed over or done in an ad hoc way.

Teams that overlook a disciplined approach to business value are leaving money on the table. Regardless of the Estimation technique used, business value should be an explicit consideration and assigned in consistent way. This will eliminate most disagreements about strategic decisions that rely on top-down decrees, intuition or luck. When business value is transparent, both Leadership and Team members can make informed decisions about how best to make the project a commercial success.

This online course details how Scrum Inc. calculates Business Value and uses it to inform our fiscal and strategic goals. Our quick but quantitative method will give you the practical knowledge you need to maximize the business value of your backlog.

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

Business value exists at the intersection of what the market wants, what the Team can actually implement, and what it is passionate about. At Scrum Inc., we generally think of business value as coming from three sources:

  • The source most people think of when assessing business value is economic value. How many units can be sold? How much can be charged per unit? And how can costs be lowered? These are important fundamental questions that need to be answered before you determine whether or not a product is worth creating. However, market value is not the only thing to look at.
  • Another important source of business value is the mitigation of risk. Before launching a new project, a Product Owner should develop a number of hypotheses about the market and then test them systematically. Activities that test these hypotheses generate value to the project and company. This is especially important if you are  in the business of innovating.
  • Testing technical assumptions also creates business value. Does the organization really have all the knowledge and tools necessary to deliver the product? If not, is the project still lucrative enough to justify procuring the necessities to make it a reality?

And finally when assessing business value, the Product Owner should determine if completing a backlog item would expand the company’s capabilities. Will the staff develop new skills allowing them to expand the company’s product line? Will leaders improve internal processes that will make other parts of the company more effective? Will refactoring a section of code eliminate a large share of the bugs that consume valuable team energy and free them up for value creating development? All these are examples of business value creation through capability building.

People often ask us at what level of the backlog should they estimate business value. Estimate at too detailed a level and you will need to perform thousands of largely meaningless calculations.  Estimate at too high of a level and you may miss important details. While the exact answer depends on a team’s unique situation, in general we find that business value is most effectively estimated at the Epic level, which generally maps to product features that can be defined completely and delivered to customers independently.

The Product Owner needs to determine how much effort an Epic will take and whether the organization has the resources to complete the project. We prioritize the backlog by return on investment (ROI), which is the business value we get in exchange for the effort/money invested to accomplish it. In Scrum, we often use the story points of an Epic as the measure of investment. Coordination with the finance department can also help this process substantially as they probably already have a defined method for evaluating ROI.

There are a number of ways that Product Owners can estimate business value, involving different trade offs between speed and quantitative rigor. It is the up to the Product Owner to decide which method is best suited for any given situation.

Commonly used methods include (from fastest to most quantitative):

Business value doesn’t have to be purely economic. Often a company is hoping to make an impact, or deliver on a social mission. The ability to accomplish these goals can also be defined as creating business value. Depending on what your company is hoping to accomplish one technique may be more helpful than another.

Back to All Topics


Read More

An Early Look at the New Scrum Book

An Early Look at the New Scrum Book

Scrum: The Art of Doing Twice the Work in Half the Time doesn’t come out until September 30th but you can read an exclusive excerpt now. Pre-order the book,  go to the book page and enter your order number then we will send you an advance chapter as an ebook.

amazon|b&n|800ceoread|iTunes

 

 


Read More

Distributed Scrum

Distributed Scrum

Distributed Scrum Teams are inherently less efficient than Teams located in the same place. The reason for this performance difference is that people working far away and at different times creates a complex array of communication Impediments. Distributed Teams almost always deliver product slower, with more bugs, and higher costs. 

Basically, if the Teams aren’t sitting together in the same room, people don’t talk as much and details slip through the cracks. Team members that don’t talk as much also don’t understand each other’s work style and are less likely to anticipate another Team members needs or feel comfortable pro-actively approaching someone to work through a problem.

As a result, any cost savings an organization may achieve from moving to a cheaper labor market often evaporates. For example, if outsourcing saves the company 70% in labor but the new Team is only 25% as productive, the company actually looses money.

Because Scrum helps Teams achieve Hyper-Productivity, it changes the basic economics of outsourcing. Scrum Inc. recommends  only distributing when looking for a skill set that is hard to find at home or when trying to serve a remote market. However,  globalization makes working in different locations a reality, so in the online course below we outline a number techniques that will minimize the damage.

Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

There are three Distributed Scrum Team configurations. Fully-integrated Teams can achieve the best results, but any of the three configurations can be effective if implemented and maintained with rigor. The common variable in deciding which configuration will work best for your organization is communication. How much do the geographically divided Team members need to coordinate to create a deliverable product every Sprint?

Isolated Scrum Team: Like any Scrum Team, an isolated Team should be cross functional, self-organized, and self-managed. It should also have all the skill sets necessary for delivering product at the end of each Sprint. However, they are working from their own Product Backlog and don’t have any common rituals such as Sprint Planning meetings and Retrospectives with the larger organization. Google’s Ad Words functions this way. Each team serves a specific market very effectively but they don’t have a formal collaborative relationship with each other.

For Google’s purposes, this configuration works fine (they generate 90% of Google’s revenue) and depending upon your companies needs, it may work well for you too. However, there are some major drawbacks. Isolating teams in this way can exacerbate cross-cultural communication issues. Commonly, outsourced teams might not even be using Scrum, and their productivity and rhythm can be more akin to typical waterfall projects. This makes communication and transparency with the home organization extremely challenging and may make the business case for outsourcing a bit dubious. This configuration only works when there is little need for the Scrum Teams to collaborate.

Overlapping Scrum Teams with shared Scrum of Scrums can help minimize cross-cultural and communication issues by linking the remote teams through a Scrum of Scrums.This allows the Teams to be in multiple-locations but work on a common project through the Chief Product Owner coordinating efforts between all Scrum Masters. These teams also share a common Product Backlog to coordinate their work. Jeff explains the Scrum of Scrums nicely in the video.

For example, if the Teams were designing a software suite that combines audio, video and text editing, perhaps one Scrum Team would be in charge of developing the video interface while another Team would be responsible for designing the text editor. Each Team would still be capable of delivering a feature set at the end of the Sprint but because the Product Owner is working from one Product Backlog and the Scrum Masters from each Team coordinate with each other as much as necessary, no Team is creating impediments for the others and the code integrates as the Team expects.

There is no formula for the Scrum of Scrums. Perhaps the graphic designers need to meet monthly, the testers weekly and the Product Owner talks daily with the Scrum Masters. The point is for the Teams to reach a certain level of communication saturation that allows them to efficiently coordinate their work.

Integrated Scrums work from the same Sprint and Product Backlog. This can be the most efficient, but also most challenging distribution model, where individual team members are at multiple locations. The best practice is to have roughly half the team in one location and the other half in another so each location has critical mass. Each part of the team should include cross-functional members to mitigate the risk that progress will be held up because someone with a critical skill is in another time zone or geography. Finally, it is important to allow distributed teams to form and gel like co-located teams. Bringing the two halves of the team together for the first few Sprints can facilitate this process.

Scrum Inc. has used this integrated configuration to deliver almost the same performance results as Teams located in the same place.

Before Teams start working together in different locations, it is important that all Team members, or at least a critical mass of them, come together for the first several Sprints. This allows the Team to get to know each other not only as people but also as members of the same Team.

By completing several Sprints together, Team members get familiar with each other in the context that they will be working: Sprint Planning, the Daily Stand-upSprint Reviews, the Sprint Retrospective (hard truths are even harder when you don’t know your Team.) It also gives developers a chance to pair in person, which can help normalize relationships quickly.

It helps to have everyone using the same tools. This means cloud based systems that allow both locations to interact with instruments in the exact same way. Everyone should get used to using the tools together during these first few Sprints.

Distribution creates communication and coordination problems but well-designed Daily Scrum meetings and high-bandwidth communication tools can help close the gap.

The most effective way for people to communicate is in pairs, face-to-face and in front of a white board where they can illustrate their thoughts and physically move user stories around. They can engage in back and forth discussions and key-in on non-verbal cues such as a skeptical or inquisitive look.

If you can’t talk in person, the next best medium is a live videoconference, followed by a phone conversation and lastly e-mail. One-way communication (a document or a recording) is even less effective.

Teams that are distributed across time zones and cultures have even more communication challenges. There is the obvious problem of just finding a common time when the Team can meet if they are several hours apart. Cultural issues can include difficulties understanding a different language, sense of humor, work ethic or how different cultures view authority. To overcome these limitations in a Distributed Scrum, we recommend a time in which the Teams can get to know one another.

Papers:

Fully Distributed Scrum: Linear Scalability Between San Francisco & India

J. Sutherland, G. Schoonheim, N. Kumar, V. Pandey, and S. Vishal, in Agile 2009, Chicago, 2009.

Fully Distributed Scrum

J. Sutherland, G. Schoonheim, N. Kumar, V. Pandey, and S. Vishal in Agile 2009, Chicago, 2009.

Distributed Scrum: Agile Project Management with Outsourced Development Teams

J. Sutherland, A. Viktorov, J. Blount, & N. Puntikov, IEEE HICSS 40th Hawaii International Conference on Software Systems, 2007.

Patterns:

Bootcamp

 

Quantum Entanglement

 

The Scrum Pattern Language of Programing : The PLoP movement codifies well know Agile practices that have been successfully implemented many times.

Back to All Topics


Read More

Writing User Stories

Writing User Stories

User Stories are Product Backlog Items that are concise and clear descriptions of functionality in terms of its value to the end user. The User Story always takes the form:

As a ______ I want to ___________ so that I can ______.”

Our experience has shown that when a Teams master producing clear, independent, and achievable User Stories their Velocity generally doubles. Scrum Inc. believes compelling User Stories are so powerful that we are developing a series of online courses to help you improve the quality of your team’s stories.

 This series will feature tips and tricks for writing powerful writing stories that:

    • Describe independently valuable functionality
    • Descriptive enough without being excessively prescriptive
    • Estimated and sized to be completed within a single sprint
    • Can be tested for success efficiently at sprint’s end

Our first installment focuses on decomposing large and complex projects into incremental vertical slices of functionality that can be delivered independently. Independent functionality is key to realizing Scrum’s potential to deliver 80% of value with 20% of the work, as well as a necessary driver of “inspect and adapt” product delivery.

 Scrum Inc.’s online courses are eligible for Scrum Alliance SEUs and PMI PDUs. See FAQ for details.

 
Frequently, new Teams have difficulty getting User Stories small enough and sufficiently specific. This should improve with time. Developing good User Stories is the most important job of the Product Owner. Working on the User Stories so that they are explicit and granular needs to be done in close consultation with the Scrum Master and the Team. Good, achievable User Stories may be the most important variable in Sprint Velocity. Often raw user stories may have multiple functions imbedded in them. In Scrum, these are called epics. From a Product Owners point of view, revenue comes from large pieces of functionality that can be shipped to a customer. However, for implementation, Epics need to be broken down into multiple stories.

The Scrum Guide defines the Product Backlog as an ordered list of Product Backlog Items. The User Story concept was developed by the original XP team at Chrysler. Ward Cunningham presented an Epidsodes pattern language at a 1995 conference which outlined the initial concept of a user oriented requirement. Discussion ensued on the XP list for the next few years and user stories were in Kent Beck’s first book on eXtreme Programming in 1999. The user story approach is so useful it has been widely adopted throughout the Agile community. About 80% of Scrum teams worldwide create user stories for Product Backlog Items.

Back to All Topics


 

Read More
content top