SM / PO Cheatsheet: Simple guide to the difference between a Scrum Master and a Product Owner

By Edward Scotcher

This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.

Scrum Master's Responsibilities

• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artefacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

Continue reading this article.

Owning an Agile Product: One CSPO's Experiences Driving Scrum Projects.

By Edward Wehr

Being a product owner and having responsibility for a product's development using agile methods can be a bit overwhelming. Creating any product can be challenge. With a product being developed at the speed of agility, these challenges increase. Nothing is more frightening than feeling out of control while going at a high rate of speed. Let me reassure you, though, that it does get better. The first time you drive down that agile highway (even if you aren't yet going fast enough), it's scary. But with practice and a good understanding of what to watch for, driving an agile project becomes easier.

Because training and certification for product owners is fairly new, I've included some wisdom I've gained from my time on the agile road, which includes guiding four different teams over the past several years.

Priorities Are Priority One.

What teams need most is a product owner who is able to prioritize the product backlog. This includes adjusting priority based on new information and juggling the team's needs for work against customer features. A product owner must understand and be willing to have the critical conversations with team members regarding stories (work) that are not direct customer features, yet will develop an architecture that will enable the team to achieve more work (higher velocity) in the future. Balancing all of these competing stories, and the emerging importance and changing priorities that come with them, is a constant struggle.

Continue reading this article.

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Cargo Cult Agile

By Manoj Vadakkan

We have been saying "there are no silver bullets" over and over again. But do we really believe that? In some ways, it is like the disclaimer we add to the end our e-mails. Nobody reads it, but the legal department makes us put it there. Aren’t we (the IT industry) treating Agile like yet another silver bullet? Everyone wants to "adopt" it! Everyone wants to say that we are Agile! It is becoming more like a "Cargo Cult" (See Notes 1).

During World War II, materials such as food, clothing, and tents were airdropped to equip the soldiers and the natives in the Pacific Islands. At the end of the war, the soldiers went home and the air cargo stopped coming, but by then the natives were used to the airdropped materials. Soon, they dressed themselves as ground controllers, wearing carved wooden head sets and waving landing signals in the hopes that these activities would attract those cargo planes.

In some cases, it seems like we just have a need to say we’re using Agile practices, even if we’re really not. We don’t use those old school requirements documents anymore, instead we create user stories. We estimate in story points; Fibonacci series is fun, and so are poker cards! Sure, we do release planning. We also do a Daily Scrum; well, we cannot really do it daily because our team members already have too many projects and meetings, so we just meet twice a week. Regarding user stories, we have to write them down in the form of detail specification because our testing team is busy with other projects and not available for the first few months to really participate. Additionally, we are required to have those documents signed by all parties, scan them, and upload them to the document management system. Otherwise, how would we know what we agreed to?

So if we think adding a daily (or mostly daily) standup meeting, estimating in story points, and implementing a few other things we find in the Agile/Scrum books will save us, well, good luck! Like the Cargo Cult, we can keep wearing our wooden head sets, lighting those run ways, and hoping for the planes to land.

Like the Cargo Cult, we are getting some of those superficial elements correct. But can we really attract the cargo planes with those elements alone? Do we really know what problems we are trying to solve? Do we really understand what we are doing and why?

In order to solve problems in your organizations, you need to look inside, not outside, to adopt yet another practice, process, or tool. You need to look at what problems you need to solve and identify solutions to those problems. Certainly, Agile/Scrum practices are proven in the industry. So bring that knowledge to your organizations in the form of training, coaching, or hiring. They can seed some of the options to get to your solutions. However, the solutions need to come from within the organization. That should be what "adopting" Agile/Scrum means. These practices need to solve the problems and achieve your organization’s goals.

Here are some activities that will help you identify problems and move towards a solution.

1. Do some soul searching: One way of doing this is to have an open space meeting. (See Notes 2)
• This will help you identify some of the problems you are trying to solve. (e.g. concept to cash takes too long)
• Help identify some of the possible solutions. (e.g. remove some of the communication barriers)
• Bringing people together will help the team take ownership of these problems and solutions instead of yet another mandated process that comes from upper management
2. Create a Product Backlog of concepts that the organization wants to try to solve the problems.
• Break those into tasks and assign resources.
3. Get senior management sponsorship.
• There comes a time when you will have to rethink the organizational structure in order to solve some issues. You can remove some of the organizational barriers only if you have senior management/leadership support.
4. Consider getting a coach, advisor, or someone who has done this before.
• A good coach will be able to guide you to possible solutions for your issues. Instead of just "adopting" some of those silver bullets like daily meetings and iterations, they will be able to guide you to solutions to the problems. A good, experienced coach can reduce the costly expense of experimenting.

There are a lot of articles out there that will help you in this transition. A comprehensive analysis can be found in Succeeding with Agile, a new book by Mike Cohn.

Have you seen Cargo Cult Agile in action? Tell us about your experience with Cargo Cult Agile.

Notes

      1. About Cargo Cult: http://en.wikipedia.org/wiki/Cargo_cult
      2. More about open space: http://www.openspaceworld.org/cgi/wiki.cgi?AboutOpenSpace

Strategist: A New Role for Scrum Organizations?

By Srinivas Suravarapu

One vague area in Scrum is vision and strategy. Most discussions about Scrum fall within the boundaries of daily scrums and release plans. What is needed is more understanding of how Scrum and a company’s vision work together. To help senior management comprehend the limitations of Scrum and to help Scrum teams visualize the big picture, each organization that wants to implement Scrum needs a strategist –someone responsible for creating a level playing field where all stakeholders and participating parties in business can contribute and add more value. The strategist’s role should be to evaluate ever-changing market trends, sales, and the organization as a whole to make sure that what engineering builds is not just feasible but valuable.

Value, in this case, is not about metrics. Value is the perceived financial gain or goodwill that a product or innovation will create. Potential sales or new business are often used as measures of this value. It is important that a strategist be able to research this kind of data and have it available before taking up a project for implementation. Feasibility is equally important in determining value. Market opportunities must be balanced against organizational capabilities. Too often companies enter markets where they do not have sufficient capabilities to compete effectively. The strategist’s job is to act as ScrumMaster of the organization, recognizing the market opportunity but evaluating it against existing capabilities, not just of the engineering team but of the entire organization.

Scrum will help a team deliver a quality product but a Scrum team, in the end, can only deliver what it was asked to create. If what was asked for is too expensive given the current capabilities or not appropriate for the existing market, the company ultimately won’t receive the value for its investment. This isn’t the fault of the Scrum framework. It’s a function of garbage in, garbage out. A strategist is essential in a Scrum organization to ensure that the needs of the market are balanced against the capabilities of the organization.

You may wonder, isn’t this the product owner’s job? I don’t think so. Not only does the product owner have enough on his plate already, he is usually not in a high-enough position to be able to see the whole picture. The strategist must be someone in the organization who has a global view and a data analysis background: a traditional strategist or senior management executive. Below are several reasons why I recommend a strategist in addition to a product owner.

• The product owner is more intrinsically oriented to the development of the product. The product owner usually comes from a business analyst or project manager background. Taking on the strategist role would require that the product owner spend too much time away from the team.
• A traditional strategist operates agnostic to the technicalities of a product and bases her job around market trends. A strategist’s strengths are non-project-management areas such as market research and trend analysis.
• A strategist has the unique ability to translate market needs into terms of financial gain for the senior management team and into terms of engineering work for development. These two components create a road map for organizational prosperity.
• A strategist acts as a liaison between senior management and the product owner to streamline communication and help both parties make well-informed decisions.

Overall the strategist should enhance the value added by Scrum. Having a strategist ensures that what senior management envisions and what the engineering team paints are in harmony not only with each other but with the market as a whole.

Definition of Done: A Reference

By Mayank Gupta

An Agile project has ceremonies (sprint planning, release planning, sprint retrospective, etc.) and metrics (sprint & release burndown charts) designed to ensure that the project is in a healthy state. Unfortunately, many Agile projects fail even after following all the ceremonies religiously. Why? One of the primary reasons is that they are not able to deliver value to the customer at the end of each sprint. They deliver a product at the end of each sprint, but not a product that is potentially shippable. Here lies the root cause of failure. The software these projects deliver at the end of each sprint is half tested, half documented, half refactored and only half ready for release.

An explicit and concrete definition of done may seem small but it can be the most critical checkpoint of an agile project. Without a consistent meaning of done, velocity cannot be estimated. Conversely, a common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects.  The definition of done is the soul of the entire Scrum process.

Before we explore a definition for done, it is important to define another Scrum term: potentially shippable product.

Continue reading this article

Two Tips to Help Product Owners with Release Planning

By Lyssa Adkins

Tip 1: Don’t let dependencies dictate when your team delivers value

Things have been going fairly well on your agile team. The team has been producing value at a regular cadence; the team members are actually working together and producing more than the sum of their parts. The team has a good idea of how much it can get done in a sprint (its velocity). The team is now asking, “When does this end?” or “When are we going to release this stuff?” or “I know we’re going to California together but I’m not sure if we’re getting there through Texas or South Dakota.” As the product owner, what do you do next? It’s time for release planning.

Hopefully, your agile coach has experience with release planning. If not, stop reading right now and bring in someone who has done this before. Release planning is not something one can learn solely from reading a book or article.

Let’s assume, though, that your coach knows what she is doing. She walks the team through release planning, so that the team members understand what they are building, have calculated the team's velocity, and have sized all the stories in the product backlog. The team members are feeling good because they now understand what work is left – they at least know if they’re going through Texas or South Dakota on their way to California. But the work of release planning is far from done. One large piece remains: choosing which stories go into which sprints.

Here’s the basic idea: stories are added to sprints until the sprint is “full” based on the team’s known velocity. How do you determine which story goes into which sprint, though? The most important consideration is business value. The goal of agile is to deliver the highest business value items first. This requires you, product owner, to order the stories according to business value. A great discussion of how you determine business value can be found in Mike Cohn’s Agile Estimating and Planning.

Let’s assume you have ordered the stories in terms of business value. Next, lay your stories into sprints starting with the highest business value story first, then the second highest, then the third, and so on. It is important you do this step first, without letting any other considerations influence the order, so that you are clear on the business value priority.

Once this is done, the next step is to work with the team and agile coach to consider all those other things only they know about: things like dependencies, both technical dependencies and dependencies on other people’s availability and their expectations. But – and here’s the trick – don’t sit back and let dependencies dictate when you do a story. While some technical dependencies may be hard dependencies that truly can’t be moved, you should. challenge all technical dependencies. Often when a team thinks about it for a while, in light of the business value they could be delivering, they realize a hard technical dependency is not as rigid as they first thought. It’s rare to find a non-technical dependency that is a true roadblock. You should push back on all non-technical dependencies. Strive. Try. Endeavor to deliver the highest business value items first – always.  If you decide to do a lower value story over a higher value story because of a dependency (like someone else’s expectations of your “schedule” or a key person’s availability) at least you know you’ve made a sacrifice up front.

Call it out. Make it clear. While it might be the only choice, or maybe even the “right” choice, doing a lower value story earlier is counter to the main goal of Agile. And, if your project is as all-fire important as your sponsors tell you it is, how many of those dependencies do you think they can alleviate? Probably most of them. 

Tip 2: Sanity check your release plan and sell it

After you have the stories laid into sprints, you can look at the release plan in a couple of different ways to see if it all makes sense. Partner with your agile coach on this. The two of you together have the insight needed to do this. Then, the team needs to weigh in. Remember that. The team always needs to weigh in.

On to the sanity checks. First, focus on one sprint at a time. Ask yourself this question about each of the next few sprints:

• Am I asking people to do too many things in this sprint? Are there too many topics to focus on?
• Is there an overload on one or two people with a certain skill set? Or, are we so heavily focused in one area that some people on the team will have “no” work? (Hint: this can be solved for over time by making room for the team to naturally cross-train.)
• Are all the “outside” things lined up, such as people you need to collaborate with, their managers, alignment on your approach or philosophy, etc.

Once you’ve done this and made adjustments at the sprint level, expand your focus again. Look across the whole release plan and ask yourself this, “What are the main storylines happening throughout the sprints and at what points does my customer get value?” Adjust your plan until you think you are delivering the most value in the fastest way possible.

After that, create your elevator speech on the release plan. Get really good at telling the story of what the team is creating and when it produces value. Get good at doing it quickly – remember that this is an elevator speech. Why get good at the elevator speech? Your team needs you to be the heat shield for them. One way to be the heat shield is to deliver this speech to your sponsor(s), other stakeholders, people who have other projects that might derail yours: vendors, venture capitalists, anyone who cares. Sure, some people will want to get deeper and, for them, you can unveil all the detail. Many others just want to be “sold” – they want to know that the team has it under control. This is one tool you can use to demonstrate that control, create alignment, and clear the way for your team to work.

And, remember that great work is never done. You will inspect and adapt the release plan with each new sprint planning session as you see what the team can bring into the sprint and what doesn’t work anymore. You will also adjust the release plan as the world around you changes. Business value priority, for example, will change according to market pressures and external forces. Let this ripple through your release plan as it happens. Just as the sprint plan always reflects reality, so, too, should the release plan.