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.

How PD works in Agile team

By Dingshan Li

PD (Product designer) is very important role in software development. They will provide detail requirements specification and business workflow, UI workflow. In traditional software development process, PD will prepare the detail requirement design document before develop team start to make software design. This kind of process will work pretty well if the requirements are clear and relatively stable. Also, there are enough PD resources to make the complex documents. But most of time, we cannot figure out the whole requirements clearly at the start stage. And the scope change is often happen. Another factor is that PD always need to work on more than one product and it is very difficult for them to spend much of time to work out a detail design document. So, what can we do to deal with this kind of issues?

Agile provides a methodology or framework for the team to develop software under the situation of changing scope. By focusing on high value requirement, separating the long lifecycle to be several short iterations and guarantee fully-test in each iteration, it can provide high-quality and expected software to the client. In this kind of framework, how PD works in the team? How they collaborate with others

Continue reading this article.

The Land that Scrum Forgot

By Robert C. Martin

Scrum is a starting point. In fact, it’s a great starting point. But, as a framework rather than a full-blown methodology, Scrum is deliberately incomplete. Some things—such as the best technical practices to use—are left for individual teams to determine. This allows a team to create the best fit between their project and environment and an assortment of technical practices.

While that selection of practices should belong to the team or organization rather than to a group of methodologists, the benefits of some practices are becoming so compellingly obvious that they warrant consideration by any Scrum team. But, too many Scrum teams become complacent after achieving some early productivity gains with Scrum. And they stop seeking ways to improve. Many fail to try the technical practices necessary for long-term success. In the following article, Robert Martin (perhaps better known as "Uncle Bob") tells us why so many Scrum teams fail to sustain the promise of their early successes.

Continue reading this article.

Heartbeats: The pace of a Scrum Team

By Rafael Nascimento

One of the challenges in the use of Scrum is to predict how much of functionality a team is able to deliver each sprint. Many try, in a vague attempt to create a metric, to assign a story point a certain amount of work to be delivered, rather than looking how a team play their roles and perform their deliveries. For example, a story point is equivalent to a CRUD with 8 fields that accesses a table in the database. This approach does not work, because a team is made up of people with different experiences, perceptions and problems (personal or professional). Individually and collectively, a team always has different emotional and technical characteristics  from other teams. Team members never take the same time that members of Team B took to adapt to each other. Teams will never manage exactly the same conflict situations or have the same productivity. Finally, in sets filled by human beings, there may even be a statistical  standard for productivity, but never an industry standard, accurate and predictable. There will always be a margin of error. Then comes a question for reflection: is it better to draft a plan and make your team follow this plan at any cost, in favor of a contract or corporate goal? Or would it be better to identify a target and track the performance and growth of your team, guiding it toward its mission, enjoying a harmonious, happy and highly productive environment, and make necessary adjustments to the project plan for the sake of your customers’ satisfaction, offering them transparency, with no surprises?

Continue reading this article.

Ouija Board Estimation

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Scrum & Gaming Addiction: How Scrum is like online gaming in creating engagement (and even addiction) in your organization

By Pete Behrens

There are few people in our Scrum Community who know personally the power of video games to engage people, and even create addictions to them. There are even some who have applied Scrum to creating those addictive online video games.

This article is not about applying Scrum to gaming applications; rather, it is about the similarities Scrum has to the gaming world in what makes them so addicting. Video gaming is one of the largest growing markets in the world at $50B this year and is on target to be three times the music industry by 2014. This year alone, there was $8B spent on virtual goods in online gaming systems - a true market indeed.

We can learn a tremendous amount from the viral and exponential growth of the video gaming industry. What makes these video games so interesting, engaging and addicting; and what can we learn about them in making our organizations more interesting, engaging, and even addicting?

Continue reading this article.

Ouija Board Estimation: A fun technique for agile estimating

By Paul Goddard

During a recent training course I ran, one of the delegates made a joke about the nature of agile estimation in Scrum teams resembling a "séance"; whereby the team gathers around the table and stares at a number of user story cards expecting something unnatural to happen. How true!  This gave me an idea for a different type of iterative estimation that I tried in practice with ‘Team Woodstock’.  I sat the team around a table and wrote the Fibonacci sequence’s numbers “1,2,3,5,8,13” and a “?” on post-its around the table in the design of a Ouija board.  Once everyone was sitting comfortably, had cleared their minds and entered a trance-like state the product owner read out the story and the team clarified the acceptance criteria.  Then the story was placed in the middle of the table and each team member put one finger on the story – in silence. Without discussion or argument the story started to move towards the number which reflected its size, by the act of the team members pushing or pulling the story towards their chosen number.

Continue reading this article.

Getting Dirty with Scrum

By Pat Guariglia

I have been the Scrum Master for this one team for several years. The other day I arrived a few minutes early to the room we use for our daily Scrum and sat down to gather my thoughts before the meeting. I was in the room by myself when I noticed all of the scuffing and marks on the walls.  When we started using this room for our daily Scrum meetings, it was freshly painted and hardly used. Two years later, I am looking at the walls of a well-used room, a room that hosts our daily stand-up meetings… a room that gets dirty.

Seeing the dirt on the walls reminded me of how tactile the whole Scrum process really is. In Scrum, you cannot be afraid to get dirty. You work with your hands, body and mind. When Scrum is done well, the team becomes a well-oiled machine that takes on a personality of its own. The seasoned Scrum team reacts organically to change and knows how to process it.

Good Scrum involves taking yourself out of the virtual world and into the real world. Unlike other software methodologies (waterfall), Scrum is the framework that thrives on continuous hands-on experiences, plus tactile and verbal feedback. It works best when people are engaged and physically involved. Collocation, physical task boards, daily Scrum meetings, and customer collaboration all require the team to be there physically.

Continue reading this article.

Have an Initial Conversation to Start an Agile Project: A CSP and CSM share how teams at Baker Hughes choose the solution delivery methodology that best suits the project.

By Rahul Sawhney and Prashant Patel

The Baker Hughes Product Development Lifecycle starts with discovery and inception phases. The delivery teams start engaging with the customers during the inception stage. By the end of inception, business requirements are understood at a high level and stakeholders from different teams who will be involved in the project are identified. This is when discussions are held for selecting the appropriate solution delivery methodology.

The choice of methodology impacts how the different stakeholders engage with the project. We have seen that in order to improve the chances of success for any project, the solution delivery methodology and the level of commitment needed should be understood upfront by all stakeholders. To that end, it is important that there is representation from multiple stakeholders, including but not limited to business, development, testing, agile coach, project management and resource management.

The stakeholders should be aware of the agile methodology and scrum framework for having this conversation. It is beneficial if they understand the rigor agile brings with respect to solution delivery and how it is different from waterfall.

Continue reading this article.

The Scrum Team: A Puzzle of People: How one CSP builds teams by inspecting and adapting

By Knut Kvarme

By definition a team comprises a group of people linked in a common purpose.

It is my experience when I get involved in discussions regarding a new project, it soon becomes a conversation about the team and who you want to group together in order to deliver within the scope defined in the project assignment.

After several years with the cross-functional team mantra at mind, I no longer think about my new team in terms of who (people). I rather think of a range of skills that I need in my team. After staffing my team I usally find that not all the skills on my list have been covered. And that’s perfectly fine!
Getting the team started and having an inspect and adapt approach in regards to the team coalition is my preferred approach. Sometimes the team steps up and gains the required skills. In those cases no further staffing is necessary.

Other times my initial list of required skills might have been wrong, and we complete the team with adding people with other skills that I thought was needed. The big advantage of this inspect and adapt staffing approach is that the gained knowledge about the tasks in hand and the observation and understanding of the team, provides the answers on how to complete the staffing of the scrum team.
So, we have a complete team with the required skills. What now?

Continue reading this article.

Beware of the Meltdown: A CSP Shares Her Meltdown Stories and Tips for Avoiding Your Own

By Carrie Schonhoff

It happens when you least expect it. At some point when a Scrum team is just forming (despite training, agreeing on team rules, and doing some team building), most teams experience a meltdown. The good news is that once the meltdown has passed, these same teams really start to understand the Scrum framework. 

From Fear to Trust

This phenomenon is not unique to Scrum. I think it happens to all of us when faced with a change that we are not prepared for. I remember when my company changed its health insurance coverage and doubled the premium. I had a meltdown!  I started thinking, “How could this happen?” “I had no idea!” “Why do we have to pay that much?” Once I talked to a couple of people and commiserated with them, I began to accept the fact that I had no choice and this was the way it was going to be from now on. I moved on. After I got over the initial shock, the changes from Human Resources didn’t seem as harsh – I understood that changes to benefits were a given.

This is how it is with Scrum. We often react defensively as a kneejerk reaction to the changes Scrum brings. It challenges the way we’ve thought about not only projects, but how we have worked in the past as well. We're forced to confront the big picture we’ve been sheltered from, yet we find it hard to see it clearly. We aren't sure how to problem-solve. And now that no one is feeding us our tasks, we are supposed to think of what to do on our own. It can be overwhelming. 

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.

The Quest for High Performance: How one CSP gets his teams off to the right start

By Tom Reynolds

Over recent months I have been working with Lyssa Adkins to improve my coaching skills. One of our areas of focus has been team start-up and our expectation that we have for our teams to become high performing. In our work together, Lyssa shared some team start-up exercises to use with new teams. I had an opportunity to put some of these ideas into practice recently and want to share that experience with the Scrum community.

Team start ups cover three areas:

• The process
• The team and individuals
• The project

This article will focus on the work I did with the process.

Starting a team off on the right foot is an essential part of building solid foundations for the team.  Don’t skip this step. It’s true that start-up exercises take some effort and thought to prepare; however, the work that is put in at the start will pay dividends further down the line.

Continue reading this article.

Adopt with Care: One CSM's 8-step approach to successfully transitioning to Scrum

By Prashant Pund

Do any of these statements sound familiar?

“Sure, we're using agile methods. I mean, we aren't entirely sure, but we think we're agile.”
“Well, the team conducts daily scrums, so they must be agile.”
“I have been tense since this guy introduced Scrum. Every morning I have to give a status report. It’s really taxing.”
“This fellow read something on the Internet about Scrum and said, let’s start Scrum tomorrow. I'm not worried. It's just another fad to ride out.”
“I heard there is a change in our process. The Process Group person is here to explain the new process, something called Scrum.”

If so, your organization likely is suffering from Scrum Mis-adoption Syndrome (SMS). SMS causes disinterest, failures to deliver, and profound distrust. The best way to treat it? Prevent it from happening in the first place.

A successful Scrum adoption requires a profound transformation of the organization. This change will be felt at the team level, yes, but will ultimately affect all layers of the organization. This then begs the question, How can I, being at the level of PM/Lead, bring in such a transformation? Shouldn’t it come from the top? The answer is both Yes and No. Yes, because indeed the transformation needs to have buy-in and support from the top. No, because a top-down approach is not sufficient. As Mike Cohn puts it, “Change is not top-bottom or (emphasis added) bottom-up; it’s both." In view of this, here is the approach I suggest to those who are trying to transition to an agile methodology such as Scrum.

Continue reading this article

From Meager Beginnings to Masterful Ends: Taking Scrum beyond IT One Iteration at a Time

By Maria Matarelli

I’ve used Scrum on many software development and IT projects.  In addition to the projects I was working on, I received a request to work on a role-advisory team tasked with analyzing the effectiveness of a specialized project role.  This new team was pulled together with minimal allocations and replaced a full-time team that had just been disassembled due to budget cuts.  Given the constraints and uniqueness of the project, we decided to use Scrum for our approach.  It worked—flawlessly.

Demanding Circumstances

The going was uphill from the start.  We were a team of ten, allocated to contribute only 20 hours per person over the entire calendar year.  The team was just told, “Go.”  Success was undefined and the scope was unclear.  With a meager budget and minimal direction, we had to guide role development, training, knowledge sharing, and create a solution to provide overall direction to support more than 150 people.  The only thing we knew for certain was that the requirements were bound to change as work progressed.

As we discussed our options, it became more and more apparent Scrum was the right approach.  The limited ingredients and project constraints were the perfect recipe for a self-directed team.  Though we could have easily made the business case for additional funding, we were told from the beginning that “additional funding is not possible.”  Any solutions we found would have to be found within the team itself.  Frequent, incremental deliveries would help bring clarity to the project vision.  Though only few of us had used Scrum outside of IT (and most of the team had never used Scrum at all) we felt it was the perfect solution for the constraints facing our team, constraints that probably sound familiar to many teams out there.

Continue reading this article.

Are We Headed to Abilene? How the Abilene Paradox Hinders Team Collaboration

By Badri N Srinivasan

Collaboration is an important aspect of any complex activity. On complex projects, a single individual cannot guarantee successful customer delivery—one that meets schedule, quality, cost, and other parameters. It takes a cohesive team.

Scrum promotes these cohesive, self-organizing teams. Scrum teams are tasked with finding the most optimal way to accomplish the work. To do this, they make decisions ranging from how best to meet goals to who should work on which tasks. Reaching group consensus can be difficult. Some opinions are more dominant than others; some voices more hesitant to speak out. Even in agreement, true consensus might not exist. One manifestation of this is the Abilene Paradox.

Abilene Paradox Explained

The Abilene Paradox happens when a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. This occurs because each member mistakenly believes that his own preferences are a contradiction to the group and, therefore, does not raise objections. When this happens, team members, in an effort not to "rock the boat," don’t voice their thoughts, desires, or intentions.

Continue reading this article.

Go with the Workflow: Focus on process instead of definitions to help new teams deal with product backlog items

By Henri Stegehuis

I love my work. Implementing Scrum is fantastic. Every company I work with has different processes and cultures. Coaching teams in this drastic new approach we call Scrum is always fun (afterwards). Working with people, breaking traditional patterns in common sense, creating a physical/visible presence, and fostering honest communication is a roller-coaster experience. Every team is unique, every time surprising me with interesting reactions and sometimes unexpected results.

In the past, some of these unexpected results have sprung from my attempts to explain the concept of a product backlog item (PBI). For teams raised in traditional development, the ins and outs of product backlog items can be difficult to grasp. When I talked with these teams about PBIs, I made the mistake of going into too much detail too early. I would start with the definition, explaining that a PBI is "up to half of an A4 page describing a requested feature from a market point of view." This, while a correct description, opened the floodgates for the skeptics and perfectionists within the team, who asserted that there was no way they could write a complete product backlog item in that amount of space. We would get off track, and it would take me some time before I could refocus the team.

Continue reading this article.

Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Agile Coaching Qualities, from A to Z

By Sunil Upadhye

Successful ScrumMasters and agile coaches share many positive qualities—listed here from A&A to Z&Z.

Attitude & Affirmations

Dress up your attitude and you can achieve 100 percent success. Affirmation is a self talk – whatever you say to yourself will be reflected in your behavior. Be kind to yourself and nice things will happen.

Balance & Benchmark

Create a balance in your mind. Be unshakable in the war against Naya – No Sayers. Create a benchmark of your work today. track the progress of your team through constant feedback mechanism.

Courage & Collaboration

Only courage can create highly collaborative team.

Determination & Desire

Have a strong determination to make others successful. Desire success. Look for the good in everyone. You will find excellent things in every human being.

Continue reading this article.

Common Product Owner Traps

By Roman Pichler

Product owners play a key part in creating successful products with Scrum: They are in charge of the product and lead the development effort. But this new, multi-faceted role can be challenging to apply. For many organizations, the path to effective product ownership is littered with traps and pitfalls. This article helps you recognize and avoid some of the most common traps.

Editor's Note: The following article was originally published by InformIT and borrows heavily from the author's latest book. It is included here for your convenience and with permission.

The Product Owner in Scrum

“The Product Owner is the one and only person responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone,” writes Ken Schwaber in the Scrum Guide (Feb 2010 edition, p. 7). This definition sounds rather harmless until we consider its implications. It requires the product owner to lead product discovery, to help identify and describe requirements, and to make sure that the product backlog is ready for the next sprint planning meeting. It also means that the product owner has to engage in product planning, visioning and product road mapping. The individual decides on the content of a release, carries out release planning, reviews work results and provides feedback to the team, and manages customers, users and other stakeholders. So many diverse responsibilities make the product owner a multi-faceted and challenging role. What’s more, the product owner duties often cut across existing roles including the product marketer, product manager and project manager roles. It’s not surprising that organizations can find it challenging to apply this new role encountering traps and pitfalls along the way. Let’s have a look at some of the most common ones.

Continue reading this article.