The Product Owner on One Page: Overview of the Product Owner Role

By Roman Pichler

The following diagram summarises the product owner's responsibility together with the role's key activities and artefacts.

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.

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.

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.

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.

How to Sustain Adaptive Planning

By Rahul Sawhney

Scrum and other agile methods recognize that responsiveness to change is an important aspect of delivering projects. They also recognize that software development is evolutionary and creative. By managing changes through Adaptive planning, Scrum provides a simple yet effective method of planning and tracking project progress. In this article, we will examine what is needed to sustain Adaptive planning and improve Team's responsiveness towards customer needs.

We will examine the following factors:

• Just-enough planning
• Evolving plan, scope driven by budget and/or time
• Grooming the scope
• Trust, involvement and collaboration
• Management support

Consider a scenario where the project is progressing as per plan, and in the middle of the project the customer approaches project manager with a request:

Customer: "I really need this functionality delivered in the project. But it is not part of the current scope. Can we make it happen as part of this project?"

Possible response #1:

Project Manager: "Unless you are okay with budget overflow and/or schedule delay. Alternatively, we can revisit the project scope but it will require us to drop certain other functionality from the scope of this project. As the effort already spent on estimation and analysis of that functionality will be wasted, please be aware that it will impact productivity."

Possible response #2:

Project Manager: "Well, I am afraid the change control board (CCB) needs to decide this. The CCB meets in two weeks and once they approve that an investigation is needed, we can investigate and inform them about the impact on our plan. The CCB can then decide whether or not this functionality can be implemented."

Possible response #3:

Project Manager/Product Owner: "I do not see a problem as long as you are okay with dropping certain low priority items from current scope of the project and getting this functionality at the end of next Sprint, assuming it fits. Let's get together and discuss."

Although many responses are possible depending on the context, if the project is using Adaptive planning then a response similar to response #3 is more likely. Such a response demonstrates that the Team is well prepared to respond to change.

Making Adaptive planning work

- Just-enough planning

To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is driven by priority. As a rule, lesser time is spent on figuring out the details of those requirements that do not have a very high priority. High priority bigger requirements are split into smaller ones so that details can be explored. Only relative size estimates (at a high level) are done at this point to get an idea of how "big" the work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements. That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). Using the Velocity, the Team is now in a better position to give commitments for later sprints.

- Evolving plan, scope driven by budget and/or time

As the project gets underway and the Team executes multiple sprints, the Team has better visibility on the customer needs. Likewise, the customer also understands the requirements better. This understanding results in evolution of the Product Backlog (e.g. changes in functionality and scope, priority).

As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product burndown chart shows how much work is remaining based on the revised scope in the Product Backlog. The work remaining is controlled usually by removing some low priority requirements (of size equal to the added requirements) from the scope. This ensures that scope is managed continuously based on highest priority requirements.

Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling many important issues, such as:

• How do we deliver what is most important for the customers?
• How do we address customer feedback on what has been already delivered?
• What are the key changes that we need to make?
• Have we addressed all the key risks for the project?
• How much work is remaining for the project? Do we need to adjust the project scope?

- Grooming the scope

At the beginning of each Sprint, the Team makes a commitment on the functionality it can deliver. In order to make a commitment, the Team may need some time to investigate certain aspects and risks in the preceding Sprint itself. In other words, sometimes it makes sense to look-ahead and reserve some time for investigation on risky items in the backlog that may be part of the next Sprint. Better insight into risky items in the Product Backlog helps the Product Owner make conscious decision on the item's priority, makes the Sprint planning exercise easier and the Team more confident.

Additionally, new functionality requests by Customers can be expected at any point during the project. Sometimes, especially when the functionality is complex or due to other reasons, identifying enough details for quickly giving commitments on these new items at the beginning of the Sprint can be difficult. Grooming the scope during a previous Sprint makes sense.

- Trust, involvement and collaboration

Working with an adaptive plan requires a lot of trust, involvement and collaboration between the Team, the Product Owner and other key stakeholders of the project. Unfortunately this is much easier said than done. Individual stakeholders have different motivating factors and it requires time to build the trust.

Things may become extremely difficult and unsustainable if the trust is lost. The effect of losing trust could result in failures such as poor quality, dramatically reduced velocity, inability to meet commitments for multiple Sprints, arguments over small stuff, high team attrition and loss of face in front of the customers.

Building trust requires a lot of commitment and collaboration. The Product Owner and management should give the Team freedom to decide how much it can deliver in a Sprint. The Product Owner needs to set the right expectations between the customers and the Team. Setting unreasonable expectations can misfire in the long term. The Team may succumb to pressure of delivering more functionality and may succeed in doing so by cutting quality, or by introducing too much technical debt that becomes difficult to handle later. The ScrumMaster needs to support the Team by guarding the scope and the practices of Scrum. The Team needs to understand the needs of the Product Owner and help in achieving that goal. The Team can help in several ways, such as improving its engineering practices, making the most out of feedback, ensuring that it acts on its retrospective actions and highlights issues that are beyond control.

The mechanism of "inspect and adapt" should not be interpreted as a "self-repairing system." The system will not fix the problems unless everyone involved in the process devotes the time needed and is committed to the process. The Team members (ScrumMaster, developers, testers etc.) need to work with each other to achieve the Team's sprint goal and continuously improve their ways of working. They need to work with the Product Owner to groom the scope and understand what is needed.

Likewise, the Product Owner needs to collaborate with the Team throughout. If the Product Owner becomes complacent in engaging with the Team after a few Sprints then the visibility of the Team can reduce drastically, benefits achieved can be quickly erased and situation can deteriorate. The Product Owner needs to ensure that the business users and customers are appropriately engaged in the process. Without an appropriate level of engagement, there is a risk of misunderstanding the business and customer needs.

- Management support

In order to sustain Adaptive planning with Scrum, it becomes important that the culture of the organization understands and respects change. Organizations, where teams go agile but the management thinking does not, run a risk of quickly losing all the benefits from Agile and becoming worse than they were before. Some of the things that managements need to do include

• Provide long term vision, direction and priorities
• Trust and motivate their Teams
• Focus on addition of business value
• Encourage Teams to deliver quality, act on technical debt, enhance engineering practices
• Ensure continuous flow of work
• Minimize non-work related disruptions
• Facilitate removal of impediments outside the control of Teams
• Support the process of learning, inspecting and adapting
• Communicate

Conclusion

Adaptive planning helps Teams handle changes to scope in a continuous manner but may become unsustainable when practiced in isolation. Other practices of Scrum, along with critical management support and understanding are critical for sustain Scrum in an organization.

Why Go Agile—Why Should I Embrace Change?

By Bachan Anand

Has someone in your organization taken time to explain to you why you should embrace Agile? Ask yourself, why would "I" as a CIO/ Business Stakeholder / Developer/QA/BA implement Agile? Teamwork is very key in any organization; however, at the end of the day, we are all individuals, and it is very important for each person to understand how Agile practices add value to their work, to their goals, and to their life at large. The good news is you will discover it once you get started with Agile as the changes are organic and ingrained into the values Agile holds. This article will be beneficial for people who have yet to take the leap and are testing the waters, and also for people who have done it all and are continuing to learn, as they can add value by sharing their experiences.

So why go Agile? No matter who you are or your role within an organization, going Agile means different things and yields different value.

CEOs –less wasted work by your organization and improves value for your investors.

CIOs – sets a compelling vision for your team, makes your stakeholder meetings easier, and improves communication with business partners at every level. With Agile you will realize an organization with higher transparency and less political agenda.

Business Users – will make them well aware of work that is in progress, and gives them opportunity to give feedback and get what they want.

Business Stakeholders – promotes transparency for business stakeholders in IT matters, allows them to see results faster, gives them an understanding of why some things take the time they take, and helps them plan better for the future.

IT Senior Leadership – provides a very concise and accurate burndown chart at each release and each iteration level. It also helps senior leadership focus on the forward thinking strategic activities while the team is focused on the short term goals.

Team Leads – puts the focus on Leads to be mentors and share with the team knowledge they have assimilated in their career.

Project Managers – puts focus on the Team to come up with a plan, with a detailed task list and estimates for every iteration, which the Team commits to. Agile sets the stage for project managers to better understand the Team and the technology, and to support the Team by removing impediments.

Architects – Agile principles focus on precision and getting it done right, architects can focus more on strategies which will take the organization to the next level of success, instead of constantly worrying about whether the team will take shortcuts.

Developers – through clear acceptance criteria, test driven development and feedback from testers during the development cycle, developers can produce bug-free code and improve their morale.

Testers (QA) – sets the stage for testers to work closely with the Team and ensure the quality of what the Team has committed to, and not be just defect finders.

Business Analyst – helps to keep the BAs focused on asking powerful business questions, and encourages them to partner with the Team to identify the expected behavior of the system through user stories and acceptance criteria.

Organizations – Imagine the growth that you can expect when the whole organization has the opportunity to constantly review and take corrective action instead of waiting for the project end phase or the yearly performance review.

Families – will improve quality of life as you will see less burn out and long hours as wasted work is reduced and deadlines are met.

Everyone – Agile is something for everyone. These are principles you can incorporate in every area of your life. It encourages collaboration at home, at schools, and church, empowering the next generation, creating a vision for yourself, and setting goals for shorter duration.

The world – think about some of the challenges that we have in our world and how collaboration, empowerment, transparency and constant retrospective can bring about changes in our political system, governments, schools, and religious organizations.

I want to end this article with a quote by Martin Luther King Jr.,–"Take the first step in faith. You don't have to see the whole staircase. Just take the first step."

Take some action and you will discover the benefits Agile provides you. Let's do it, Let's go AGILE!!

Three Things I Wish I Knew Before Jumping

By Pat Guariglia

Like many people trying to implement a Scrum/Agile project for the first time in an organization, I encountered a number of obstacles that were almost project killers. As I write this article today, I keep thinking, “if I only knew that when I started.”

When I started managing my first Scrum pilot project in 2007, I was new to the concepts of Scrum and Agile development. For years, I led projects using traditional project management methodologies common to PMI, i.e. Waterfall. During this time, I was a consultant to a New York State Agency. It was a typical Waterfall shop, with no history of using Agile or Scrum.

Sometimes you can choose the project you want to pilot, but oftentimes the project chooses you. In my situation, the Agency had its back up against the wall and needed to expedite the delivery of a critical project. Agency funding was in jeopardy and critical business dates needed to be met. In my opinion, certain types of projects are good candidates for Scrum pilots, and others are not. The project I led had none of the characteristics ideal for a pilot project; it was not the perfect candidate for a first-time Scrum implementation.

After being assigned to manage this project, I quickly realized that the project would never meet the deadlines within the constricted structure of the organization. It was necessary to break away from the Agency’s normal project management and development methodologies. The project sponsors permitted us to use the methodology of our choosing as long as we met the deadlines. I explored Scrum and various Agile methodologies and made the decision to abandon the normal Waterfall project path.

After one year, the pilot project turned into a program of three projects. Two of the projects used Scrum and the third followed a Scrum hybrid approach for managing a vendor’s customization of a commercial software product. The program was mostly successful, and the projects were delivered on time for all critical dates. The organization was satisfied with the use of Scrum and looked for other project opportunities to leverage some of our Agile best practices.

The first few months were difficult and outright painful as the team learned the practices of Scrum, the variations of Agile development, and the nuances of the customer’s business. Our team had little guidance and no one coaching us on Agile or Scrum methodologies. For months, we worked in the dark to avoid scrutiny and work out the details of our methodology, with only a few people aware of our voodoo methodologies. We had only one clear goal, to achieve the deadlines without failure.

Even though I had moderate success with the three projects, I discovered literally hundreds of things I wish I knew before setting off on my pilot journey. I want to focus on three critical topics for this article, which I believe anyone starting a Scrum pilot project should know. The three things I wish I knew most before jumping into my first Scrum project are: 1) select a project with medium criticality; 2) continuously communicate your chosen methodology; and 3) demystify the voodoo (this one needs some explaining).

These three topics are basic and straightforward, and should be universal to anyone attempting an Agile/Scrum pilot project for the first time. I chose three things that focus on the early stages of a project, but could also be valuable throughout the project’s lifespan.

Select a Project with Medium Criticality

In order to have a successful Agile or Scrum pilot project, it is important that the project chosen has enough importance or criticality to the organization. Projects with low levels of urgency will get brushed off and not given the resources, attention, and critical thinking needed to properly develop a Scrum project. Pilots with high criticality are not good for several reasons. The main reason is that there is little room for failure. If the pilot is not successful, it can be a huge black eye on the face of future Scrum efforts. Also consider that on a project with high criticality there will likely be many attitudes and influences on the project, which could steer it off the Scrum course.

Typically, good candidate projects have medium importance to the organization. It is important to understand this when choosing a pilot, if you are selecting one from your portfolio. An excellent resource on this topic is a book by a friend of mine, Greg Smith, titled Becoming Agile in an Imperfect World. He covers various aspects of a good pilot project in his chapter “Characteristics of a Good Pilot.”

Continuously Communicate Your Chosen Methodology

I cannot express the importance of this topic enough. In the years that I have been a project manager, I have never been able to communicate enough. Just when you think you have covered all bases, there is someone lurking in the shadows not paying attention. According to PMI¹, the amount of time a project manager spends communicating is 90%. This holds true for Agile project managers and ScrumMasters as well.

Since I have been using Scrum, I have been both a ScrumMaster and project manager on each project I manage. As a ScrumMaster, I have spent countless hours coaching and deflecting potential issues/problems away from my team. As a project manager, I have spent an inordinate but necessary amount of time reporting status, building relationships with stakeholders, and keeping the projects aligned with the organization’s standards, rules, and strategic goals.

When starting a Scrum pilot project of any type, it is of vital importance to communicate your chosen path (Scrum) to everyone you interface with. You should not communicate this path just once or twice. It will be necessary to continuously express, elaborate, and explain Scrum to every stakeholder and team member until they no longer look at you with confusion in their eyes.

After more than a year and a half into my pilot Scrum project, I was talking to a functional manager about our Scrum methodology and how we were using Scrum and Agile development. The manager appeared confused and disoriented by the conversation. This was not the first time discussing this methodology, but the manager reacted as if it were. This reaction is common in an organization heavily framed within a Waterfall methodology.

Typically, few people in traditional Waterfall organizations have been exposed to Scrum. I made the false assumption in the beginning and middle of my pilot project that stakeholders and the accidental support person were familiar with Scrum or Agile development, because I gave several overview presentations to them. This assumption was way off on my part. In order to understand Scrum, one needs to be involved in Scrum. Observing Scrum from the outside can be odd for some, and for others it can be confusing.

After many months of trial and error, our Scrum team finally reached a cadence and became better at estimating and delivering. The people who interfaced with us on a regular basis, who were outside the immediate Scrum team, including support units, infrastructure, and the PMO, began to better understand the Scrum process. If your pilot project is progressing successfully, it will become easier to communicate your process because everyone will want to know how you are doing it. On the contrary, if your project is lagging or plagued with issues, it will be hard for you to find an audience that you can convince that Scrum is the way to go.

Communication on any project is the most important part of a project manager or ScrumMaster’s job. The sooner and more frequently you communicate what you are doing the better off you and your project will be at surviving the first Scrum attempt.

Demystify the Voodoo

In my attempts to “demystify the voodoo” of Scrum to the outside observer, I have realized that this is not always an easy task, and is one that requires frequent attempts at demystification. When I first started using Scrum and Agile it was painfully obvious that others in the organization, including some stakeholders, were uncertain about my methodology and had a preconceived notion about Agile and Scrum. This misconception was something I continuously confronted throughout my project, as it was an impediment to my progress.

The reason voodoo becomes an impediment is mainly due to the reasons mentioned above in the communication section. It is important to communicate the methodology, which means define, describe, demonstrate and illustrate, thereby demystifying whenever possible. Most of the voodoo comes from not understanding the methodology or having the wrong information. Agile and Scrum are demystified every time one communicates or explains their pros and cons to the outside observer or reluctant stakeholder.

Unfortunately, as a project manager and ScrumMaster, it is possible to contribute to the voodoo perception. Performing Agile “in the dark” or “under the radar” can sometimes make the methodology even more taboo or misunderstood. Performing this style of clandestine Agile can be beneficial for a short period while the project team is getting up to speed and processes are being defined, but continuing too long in this mode will eventually be counterproductive. Stakeholders want to understand how the project is being managed. At some point, it is necessary to communicate the methodology before others begin forming their own opinions of what you are doing.

Using examples of public success stories also helps to demystify Scrum. After articulating various definitions of Scrum and Agile development processes to my stakeholders, I looked for examples of successful implementations of Scrum in both the private and public sectors. Illustrating how a CMMI²level 5 company can successfully put a Scrum project into place certainly got the attention of some of the stakeholders. I showed quantifiable results from Systematic, a CMMI 5 company who measured productivity and quality before and after they implemented Scrum. Their overwhelmingly positive results put many of my stakeholders finally at ease.

Wrapping Up

Though there are many things I learned along the way, the few that I have described here are the ones that would have been the most helpful at the start of my Scrum/Agile experience. If you have any choice in the matter, remember that when starting your first Scrum pilot project, it is important to pick the right project. Also, communicate your methodology, risks, and plans continuously. And finally, provide accurate and substantive information to support the use of Scrum and Agile in your organization, which in the long run will demystify the aura of Scrum.

Scrum is not a cookie-cutter mold that you can throw your project into. Scrum is adaptive and can be customized to some extent to fit the unique situations and conditions of your environment.

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

The Sprint Review: Mastering the Art of Feedback

By Bob Schatz

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.

First, let’s understand what the purpose of the sprint review is.  As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”

Focus on the End User

Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.

That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.

We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.

Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station.  It was an environment of high-energy, excitement, and fun.

Involve the Product Owner

You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.

Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown.  He should then let the reviewers know what they should be looking for and how to provide the feedback.  After setting the stage, the  Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.

Understand Group Dynamics

Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.

Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.

Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for.  Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.

Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.

End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.

ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.

Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.

Be Courageous

If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.

Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.

The Product Vision

By Roman Pichler

True North

Have you ever worked on a Scrum project where the overall goal was not clear? Where you had a product backlog but the people involved in the development effort only vaguely understood the purpose of the release? It happens more frequently than any of us would like, even on projects with multi-million dollar budgets! Often Scrum’s emphasis on “getting work done” is misunderstood as a rush to develop with not enough thought to where the project should be going. Don’t make that mistake. Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders. As Ken Schwaber puts it: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” (Schwaber 2004, p. 68)

Five Questions

“Vision is the art of seeing things invisible,” observed the English writer Jonathan Swift. The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision entails carefully answering the following questions:

1. Who is going to buy the product? Who is the target customer? 
2. Which customer needs will the product address? 
3. Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? 
4. How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? 
5. What is the target timeframe and budget to develop and launch the product?

Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.

Creating the Product Vision

Since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team (Pichler 2008). For innovative projects, this team may include business and technical people; for instance, marketers, product and user interface designers, and developers. The more innovative and complex the product is, the more important the vision is and the more effort is required to create it. For new-product development projects and major product updates, market research and prototyping activities are usually carried out. Since it may take several weeks or even months to compile the relevant information in this case, running one or more sprints is the best way to carry out the necessary work. Contrast this with a small product update or a maintenance release where creating the vision may only take a few hours or days.

The Heart of the Product Vision

At the heart of the product vision is the description of the selected customer needs and the necessary product attributes meeting those needs. To arrive at this vision, we first select our target customers and then the relevant customer needs, thereby deciding which market or market segment we are going to address. Then we identify the product attributes, those critical high-level requirements the product must fulfill to satisfy the needs.

Product attributes typically comprise both nonfunctional and functional requirements. Nonfunctional requirements include performance, robustness, and usability requirements. Functional requirements describe specific product functions or features, for instance making a call or sending an email. The product attributes serve as a guide for the team; they constrain the solution space – the set of all possible solutions.

Describing product attributes at the right level of detail is a balancing act that requires close collaboration between the Product Owner and the team. Under-specifying attributes causes a lack of guidance and direction. Over-specifying product attributes results in making decisions earlier than necessary and negatively impacts the team’s creativity. The techniques useful to describe attributes include personas and scenarios, use cases, and user stories.

Desirable Qualities

Like any important goal, a good vision equally appeals to our intellect and to our emotions. It should motivate and inspire people. The product vision should be clear and stable; broad and engaging; and short and sweet.

Clear and Stable

The product vision must be clear and easy to understand to create alignment and a common purpose, and to avoid misinterpretation and confusion (Lynn&Reilly 2002, Pichler 2008). The English term vision is derived from Latin visio, which translates to “seeing, view, notion, idea.” The product vision should hence allow us to see the future product. The vision should not be fuzzy or hazy.

Vision changes, particularly with regards to customer needs and critical attributes, can cause confusion, de-motivation, and project failure. Small adjustments are usually fine, as long as the product’s value proposition stays the same.

Broad and Engaging

The product vision should describe a broad and engaging goal: a goal that guides the development effort but leaves enough room for creativity; a goal that engages and inspires people, fosters creativity, and generates buy-in.

Short and Sweet

The product vision should be brief and concise (Pichler 2008). It should contain only information critical to the success of the product. The blockbuster products researched by Lynn&Reilly (2002), for instance, had visions with no more than six product attributes. The product vision is, therefore, not a feature list and should not provide unnecessary detail.

The Elevator Test

The classic way to validate the product vision is to answer the elevator test: “Can you explain your product in the time it takes to ride up in an elevator?” Moore (2006, p. 152). Passing this test ensures that your product vision is clear, engaging, and brief (assuming we ride up a building with the right height and don’t get stuck). Notice that the elevator test does not tell us if we have selected the right customer needs and the right product attributes; only early customer feedback can do that.

Business-as-Usual Projects

Even our business-as-usual projects should be guided by a product vision. For example, I manage my own marketing activities using Scrum. I fill my marketing backlog with new items on a regular basis, sometimes as frequently as every other day. It would be an overkill to carry out market research and prototyping activities before I decide what to work on. Instead, I set myself a marketing vision that guides my work and provides focus. My vision is, by design, less substantial than the vision for a new-product development project but it’s still important that I have one.

Summary

An effective product vision guides the Scrum team and aligns stakeholders and customers. Spending time and money on vision creation is a worthwhile investment. As Robert G. Cooper notes: “Too many new-product projects move from idea stage right into development with little or no up-front homework. The results of this ‘ready, fire, aim’ approach are usually disastrous. Solid pre-development homework drives up new-product success rates significantly and is strongly related to financial performance.” (Cooper 2000, p. 3) This does not mean procrastinating the start of development, using an upstream waterfall process that creates a mighty product concept or employing a separate project. The trick is to spend as little time as possible but as much as required; to use Scrum to create the vision; and to ensure that as many of the team members involved in the vision creation as possible also transform it into the actual product.

References

Cooper, Robert G. Doing it Right. Winning with New Products. Ivey Business Journal. July/August 2000.
Lynn, Gary S. and Richard R. Reilly. Blockbusters. The Five Keys to Developing Great New Products. HarperCollins. 2002.
Moore, Geoffrey A. Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers. Revised edition. Collins Business Essentials. 2006.
Pichler, Roman. Scrum – Agile Projektmanagement richtig einsetzen. dpunkt.verlag. 2008.
Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press. 2004.

Going Nowhere Fast: Scrum without a Product Owner

By Jim York

Like Donkey, riding in the back of the garlic coach on the way to Far Far Away in the movie Shrek 2, too many product owners are taking a back seat in Scrum by limiting themselves to asking, “Are we there yet?” Little wonder. Accustomed to decades of “over-the-wall” requirements handoffs and long delays before seeing a working system, many product owners are disenchanted and ill-prepared when faced with the immediate, persistent, and unrelenting demands of a Scrum team. What was “Far Far Away” is Now. Here. Today. Product owners aren’t prepared.

When acting as ScrumMaster, I’ve found that I spend at least 50 percent of my time working with the product owner and the myriad of stakeholders the product owner represents. When you introduce Scrum to a new team, find out who the business sponsor is and make sure she understands the pivotal role that the product owner plays. The product owner is ultimately accountable for maximizing the return on investment (ROI) for the project. To succeed, the product owner must establish and communicate the project vision — the elusive “it” that constitutes real value to a real customer. Then the product owner must nurture that vision by frequently inspecting the working features produced by the team and providing timely feedback. When reality deviates from the plan, the product owner works to adjust the plan to match reality while keeping the team focused on the vision and holding together the coalition of stakeholders.

The days of handing over a requirements document and then sitting back to wait for the delivery team to finish are over. Product owners don’t belong in the back seat. They must be immediately available to the team. My rule of thumb for a product owner is that they must ensure that 80 percent of the Scrum team’s questions are answered within five minutes of the question being raised. To achieve this level of responsiveness, the product owner really must be engaged and must engage subject matter experts to be available to the team when necessary. This isn’t a role to be taken lightly.

Get ready product owners because, like Donkey, you definitely aren’t in the swamp anymore.

Being an Effective Product Owner

By Roman Pichler

When I met Paul, a first-time product owner on a new project, the first thing he asked me was, “What do I really have to do and how much time will it require?” Even though Paul had attended a Scrum introduction a few weeks back, he wanted to double check his responsibilities. He was worried about the time commitment he had to make and the support he would get from his boss.

Helping product owners like Paul getting started is rather the norm for me. In most organizations that I have worked with, product owners are strapped for time, are often not aware of their responsibilities, and are unsure how they should best transition into their new role. Sadly, I have also met many product owners on Scrum projects who resembled more a business sponsor briefly stopping by at the sprint planning and review meeting or an on-site customer interacting more frequently with the team but leaving it to the ScrumMaster to guide the team.

So what is the product owner in Scrum supposed to do? The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.) In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out. I have experienced that having a strong, empowered, and present product owner is a key success factor for Scrum projects – just like a strong, empowered team is. Most projects I have come across that had product owners who were not properly available or empowered suffered, and the projects never reached their maximum velocity.

I have found three things particularly helpful for product owners: a thorough understanding of the customer needs, an active stakeholder management, and a basic knowledge of how software is developed and deployed.

Thoroughly understanding the customer needs and how the product will satisfy those needs allows the product owner to describe, prioritizes, and communicate the requirements that really matter and answer all related questions. The product owner should express what value-added is from a customer perspectives and focus the development efforts toward providing that value.

Proactive stakeholder management is particularly important in larger organizations, where the stakeholders include not only customers but also internal functions, such as production support, service or sales, as well. Taking into account and prioritizing the various interests early on and involving stakeholders regularly, for instance in form of user story writing workshops and sprint reviews, is crucial to ensuring that the software can successfully work in its target environment.

Knowing (at least roughly) how good software is developed makes it easier for the product owner to closely communicate with the team. This kind of knowledge helps product owners to better understand how the team works and how important quality and the related agile technical practices are to sustain a high velocity across releases.

This broad skill set implies that ideally, the product owner would be a hybrid: someone who is able to look outward, understanding the end customer needs, and someone who looks inward, managing the value stream that transforms the customer needs into software ready to be used by the customer. Toyota’s Chief Engineer role very much resembles such a hybrid product owner: The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s.

So what did I tell new product owner Paul? Well, I took him through the key activities a product owner has to perform on a Scrum project, from hosting estimation workshops and prepping for the sprint planning meeting to giving feedback to the team and accepting or rejecting work results in the sprint review meeting. I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available. We scheduled the first user story writing workshop with the team and stakeholders, and we set up the first effort estimation workshop. I also volunteered to talk to his manager about Scrum and to explain why it is so important for a product owner to spend enough time with the team every day and to be able to make decisions on the spot.

Being an effective product owner is not easy – nor is being a good ScrumMaster. To get started, be aware of the core responsibilities the product owner has and make sure that the product owner firmly sits in the driver’s seat – all the time.

Scrum Smells: Talking Chickens

By Mark W. Randolph

Importance

Important

Symptoms

These are symptoms that a Scrum team is not being protected from outside influences:

• External stakeholders talk in the daily Scrums
• Features are selected or priorities switched outside of sprint planning meetings
• The team cannot make purely technical decisions without an outsider’s blessing
• Status reports are required outside sprint planning meetings
• Team managers or executives who sponsor the team receive requests to influence the team
• Product backlog languishes or is ignored

There are many different types of outside influences. Only one example of outside influence is examined here: talking chickens.

Discussion

To explain the difference between a Scrum member living the pain of a bad technical decision and outsiders who feel compelled to make decisions for a team, Ken Schwaber [1] talks about a pig and a chicken opening a restaurant. The chicken suggests the restaurant be named Ham and Eggs. The pig suddenly realizes the difference between being an interested stakeholder and full commitment. After all, it is easier to contribute eggs than to be the entrée.

Scrum teams work best as self-organizing teams protected from incompletely informed decisions imposed by external stakeholders. An external stakeholder is someone who does not directly participate in development and is not a member of the Scrum. Typically, external stakeholders:

• Use or benefit from the use of the product, or are affected by product use;
• Contribute resources or pay for a product’s development; and/or
• Set priorities, budgets or schedules; and/or
• Do not suffer the full pain of bad technical choices (late nights, lost weekends, etc.).

In the context of Scrum, external stakeholders are chickens. Scrum team members are pigs.

While inappropriate outside influence can be exerted at any point in a sprint cycle, it is most visible when external stakeholders overparticipate in daily project activities, especially the daily Scrum, which explains the rule, “Chickens don’t talk at the daily Scrum.”

Note that external stakeholders have a legitimate interest in the success of the team and that the team cannot succeed without their contributions. That is the irony. Even if developers know best how to define and deliver valuable features, deeply useful products cannot emerge without the cooperation of the executives, customers, managers, and the others that the team serves. Chickens and pigs must collaborate to deliver a meal because, in the end, it is everyone’s bacon.

Why are the chickens clucking? Is it:

Ignorance? Maybe the chicken is an ignorant chicken. Have the rules been explained?

Weak enforcement? Is the no-talking-chicken rule consistently followed? If it is not, what is preventing the ScrumMaster from enforcing the rules?

Failure of support? Are the attempts of the ScrumMaster to enforce the no-talking-chicken rule undermined by team members or team sponsors?

Habit? Are chickens fighting old habits of immediate unimpeded access to developers? Do they lack experience with the rhythms of sprint and release planning?

Lack of faith? Do the chickens lack faith that Scrum can deliver what they need? Has the team done something, for example ignored priorities or been late, that has undermined their credibility so that chickens feel compelled to intervene?

Contention for control? If two or more groups are contending for development resources or priorities, that competition may manifest itself in efforts to direct the work of the Scrum.

Legitimate input? Did the team invite the chicken and ask for their contribution? Maybe the chicken ought to be brought into the Scrum.

Remedies

While it is tempting to offer a talking chicken a rubber band for their beak, or a chopping block for their neck, tact and discretion might compel you to consider other alternatives:

• Consistently enforce the no talking rule
• Conduct training as part of project start
• Negotiate rules at project start
• Use retrospectives to reinforce expectations
• Move chickens away from the pig pen
• Change the meeting time and place and don’t tell the offender (just kidding)
• Maybe the chicken can lay an egg
• Become a barnyard dog

Additional explanation follows.

Be consistent

Habit is your ally. Consistent enforcement develops habit. Mike Cohn tells this story [2]:

A few months ago I took my young daughters to a local fair. On one ride, the line led up to a short flight of stairs at the base of the ride. No one was allowed on those stairs, but many of the young kids wanted to sit on the stairs while waiting. The ride operator, though, held firm to her rule of no one on the stairs. She told them, “If I let you sit on the first step soon you’ll be on the second step and then the third step.” Clearly sitting on the first step would not have endangered any riders but the stairs were an obvious delineation and the ride operator used this as her simple rule. Not allowing chickens to talk during the daily meeting is one of Scrum’s simple rules. Of course one comment from a chicken may not hurt—but it will lead to others and then there will be no easy place to draw the line.

Never allow a violation that can be avoided. When a violation occurs, take action. If everyone is already familiar with the rule, a reminder during the meeting is appropriate. If the chicken might not be aware of the rule, speak to them privately immediately following the Scrum. If there is a single consistent violator, find out what the root issue is (“My priorities are being ignored”), and deal with that directly (“You have to start attending sprint planning meetings”). Bump the violation to the individual’s supervisor or the team sponsors and ask them to intervene.

Conduct training

Prevention is easier than correction. Make training a routine part of every project start and include potential chickens. Explain the rationale of the “no-talking-chickens” rule, and solicit a public commitment from everyone to cooperate.

Have a contract

As part of project start, help the group—Scrum members and stakeholders together—negotiate a set of rules of how to work together. One rule should always be, “Chickens can observe daily Scrums but may not participate.” As part of the discussion, talk through alternatives to attending and speaking at a daily Scrum. For example, “On this project, if a chicken has an urgent request that cannot wait for sprint planning, they can take it to the ScrumMaster and the ScrumMaster is obligated to act on the appeal.”

Use the retrospective pro-actively

Every sprint includes a period of retrospection during which the sins of the past are remembered, and pledges are made not to pass that way again. Relive incidents where the no talking rule was violated, explore the reasons for the violation, and discuss the consequences or potential consequences of the violation. At the very least, if it has been a problem, remind everyone of the no talking rule. This will help forestall reoccurrences.

Move chickens away from the pig pen

Shamelessly exploit unconscious human behavior! In group settings, the next person to speak is frequently the last person to make eye contact with the group leader or the last speaker. Arrange the room so that chickens are outside the circle of the Scrum and behind the ScrumMaster. They can’t make eye contact and are less likely to participate.

Bring the chicken into the Scrum

If the chicken is attending because they must be consulted or have valuable input related to development (clarification of requirements qualifies as development), maybe the chicken ought to be brought into the Scrum. Maybe the chicken can lay an egg.

Become a barnyard dog

It is the ScrumMaster’s job to protect the team from interference. A properly empowered ScrumMaster has the authority to exclude chickens from the Scrum entirely.

Case history

We had an executive notorious for micro-management. True to form, the executive attended the first daily of the first sprint of the first Scrum project and peppered the team with questions. Afterwards, the ScrumMaster—with great trepidation—explained that while observers were welcome, the meetings were for coordinating work, not problem solving. The executive’s response was, “Oh. Right. OK.” Seizing the opportunity, the ScrumMaster then urged the executive to come to sprint planning instead, offering these arguments specifically tailored for this particular executive:

• We’ll have a working demo ready
• The daily meetings are low level and technical, whereas the Sprint meeting is at the business level, and you can see what your customer is going see
• All your stakeholders will be in one place, the developers will be prepared for questions, and you can get really good information
• The team will be done with one batch of work, and ready for you pick what to work on next
• We have these every Monday (we use one week sprints), so you can arrange your schedule for months in advance

The executive was agreeable, and the idea of a demo was exciting. The executive did attend several more dailies, but within a week, declared them “boring” and stopped coming. After attending only a few sprint planning meetings, the executive was quite enthusiastic about the sprint model. “I like it!”

The lesson? The ScrumMaster took action immediately, and anticipating the needs of the particular stakeholder, offered opportunities other than the daily Scrum to get those needs met.

References

Schwaber, K. 2004. Agile Project Management with Scrum. Microsoft Press.
Cohn, M. 2003. Toward a Catalog of Scrum Smells. www.mountaingoatsoftware.com

Contracts for Implementing Scrum

By Dan Rawsthorne & Douglas E. Shimp

Introduction

Scrum provides the essential framework that an organization needs to create high-performing, rapidly-responding, product-producing software teams. It gives organizations the tools to develop a working product in the face of complex domains and shifting organizational needs. Successfully implementing Scrum, though, requires commitment both on the part of the Scrum team members and on the part of the organization. This has led us to create a list of promises, a “contract” if you will, that gives both teams and organizations a familiar framework for understanding what is necessary for Scrum to succeed and for communicating a sense of ownership by all parties involved.

Intent of the Contracts

These contracts are not meant to be recognized in any legal sense; rather, they are for raising awareness of what is required for a Scrum implementation to work. And remember, even with best intentions, promises are sometimes broken. What is important is that the parties involved commit to a good faith effort to recommit to the promises when this occurs, and to resolve issues whenever they arise.

There are two starting contracts, each containing unique promises. The first contract is between the organization and the Scrum team. The second contract is within the Scrum team and its various parts. Both contracts consist of promises that when kept will maximize the chances of achieving the full benefit of a Scrum implementation.

Scrum provides a working framework, not an “out-of-the-box” solution. Because each organization’s inherent complexities (both product and cultural) are unique, Scrum requires that the Scrum team conduct a periodic “inspect and adapt” analysis. The Scrum team incorporates the results of this analysis into its own processes and the organization incorporates the results into its deployment of Scrum. Therefore, as the organization learns what Scrum means to them, they should periodically reconsider any contracts for implementing Scrum and modify the contracts accordingly.

Parties and Definitions

For the purposes of this contract the following parties and terms are defined. The organization is the business or entity with administrative responsibilities and functional structures, intent on successful delivery of the product. Stakeholders are parties with an interest in the product being developed and/or the Scrum process. They might include suppliers, customers, the business owner, subject matter experts, or product support. The business owner is a key stakeholder who supplies resources for the project. The Scrum team members are also stakeholders, with an interest in the product, process, and project.

Scrum is an empirical development process framework for solving complex problems. Scrum defines three distinct roles that must work together as a Scrum team to produce a successful product. The product owner is responsible for understanding what stakeholders require, interpreting these requirements for the team, and providing clear prioritized direction. The team is composed of those people actively engaged in building the product. The team collectively and members individually are responsible for building the product according to the priorities and requirements provided by the product owner. The team is completely responsible for deciding how to achieve its goals and how to organize its work. Finally, the ScrumMaster is responsible for the health of the process, reporting the progress of the team, and removing impediments to progress.

Period of the Contract

Again relying on Scrum’s framework, we need an “inspect and adapt” analysis of the Scrum implementation. The Scrum team incorporates the results of this analysis into its own processes and the organization incorporates the results into its implementation of Scrum. Additional promises may be required as a result of this analysis.

Decide how often your organization will review and renew the contract:

This contract will be renewed each ____________ (specify period) by retrospection, facilitated by the ScrumMaster and product owner. If at any time the process is found to be inactive, a reimplementation of the contract and the process will be required. Reimplementation is the responsibility of the organization.

Contract between the Organization and the Team

The team promises the stakeholders that there is a product owner on the team driving the team based on stakeholders interests.

The organization promises the team that there are stakeholders (including subject matter experts) who will help when needed.

The team promises to use the stakeholders’ time wisely, by focusing on questions that are relevant to the work being done now.

The organization promises that they will help the ScrumMaster in the removal of impediments to the Scrum team’s progress.

The team promises that they will do quality work the best way they know how within the constraints set forth by the organization.

The organization promises the team that they will not change priorities or constraints in the middle of a sprint without team’s consent.

The team promises to deliver demonstrable product at the end of every sprint for review and validation by the stakeholders.

The organization promises that being on a Scrum team will not hurt the members’ careers.

Signed on this date:______________________

For the organization

Key stakeholders representatives

x___________________________

x___________________________

x___________________________

x___________________________

x___________________________

For the Scrum team

ScrumMaster

x___________________________

Product owner

x___________________________

Download a PDF of this contract.

Contract between Members of the Scrum Team

The product owner promises the team to he/she will supply an initial product backlog.

The product owner promises the team that he/she will prioritize the product backlog when needed.

The ScrumMaster promises to keep the team healthy by focusing on the removal of impediments, both internal and external.

The product owner promises that an empowered “voice of the customer” will be provided to answer business domain questions promptly (minutes or hours, not days).

The team promises that its work will be transparent, that it will make decisions and solve problems as a group, and that no individual team member will be left behind.

Each member of the team promises that they will bring issues, problems, impediments and realities encountered to the team.

Signed on this date:______________________

For the Scrum team

ScrumMaster

x___________________________

Product owner

x___________________________

Team members

x___________________________

x___________________________

x___________________________

Download a PDF of this contract.

Top 7 Responsibilities of a Scrum Product Owner

By Laszlo Szalvay

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. The Product Owner is the one person responsible for a project’s success. In other words, if a project flops, it’s the Product Owner who must face the music. What follows doesn’t include every activity a Product Owner should consider or every rule he or she should follow. In fact, trying to account for every conceivable demand placed on a Product Owner would be impossible. But this list of seven do’s will help aspiring Product Owner make sure they’re covering the basics.

1. The Product Owner leads the development effort by conveying his or her vision to the team and outlining work in the Scrum backlog. The Product Owner drives a project by communicating directly with the team, while visually demonstrating prioritization decisions in the backlog.
2. The Product Owner prioritizes work based on Business Value. Scrum is unique its reliance on empirical data to inform development decisions. Thus the Product Owner prioritizes a team’s work based on the Business Value it will generate.
3. The Product Owner negotiates work with the team. At the beginning of each sprint, the team and the Product Owner meet to determine what work will be tackled for the sprint. However, this work is negotiated, rather than merely assigned. It is the team’s responsibility to update the Product Owner about any impediments obstructing progress to help ensure that prioritization is fully informed. Likewise, the Product Owner must respect the team’s established velocity—a metric used to track how much work a team can accomplish in a single sprint.
4. The Product Owner must remain available to the team to answer questions and deliver direction. Because the Product Owner best understands the vision of the project, he or she will want to remain highly accessible to the development team to clarify acceptance criteria, articulate customer desires, and so on.
5. The Product Owner must resist the temptation to micromanage. Because the Scrum framework vests the Product Owner with authority over the team, while asking that he or she remain available to the team, it is extremely common for a Product Owner to be tempted to behave like a traditional manager and micromanage the team. However, Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan for completing sprint goals.
6. The Product Owner must resist “raiding the team’s sprint.” For Scrum to yield hyper-performing teams, teams must be given the entirety of the sprint to complete work without interruption. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint, which is often referred to as “raiding the sprint.” Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner cannot alter the sprint until the next sprint planning meeting.
7. The Product Owner must not be afraid to make tough decisions. Because the Product Owner is the single person responsible for whether a project sinks or swims, he or she must have the confidence to make decisions that are best for the business. These decisions may be unpopular with the development team, but the Product Owner must consider the expectations of stakeholders and customers first.

6 Tips for Good Scrum

by Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?

The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritization.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry.  Why not come along to the next one, we could use your input.

New Version of ScrumEdge Goes Live

We are pleased to announce that a new version of ScrumEdge has been released today. We have added many new features in this release and resolved some issues reported by our users.

Major Updates:

• Interface: We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with. The use of bigger fonts should make text more readable and some slick progress bars will give users the ability to check out project, sprint, story and task level progress at a glance.
• Projects Dashboard: We have introduced a new project level dashboard that all users will see when they sign in. This page will display all projects the user is assigned to along with a basic snapshot of the number of sprints, stories and users that are assigned to each project. Progress bars will allow users to see project progress at a glance. Clicking on any project should take users to their main dashboard.
• Story and Task Efforts: More detailed Story and Task Effort level reports will allow ScrumMasters and Product Owners to follow their sprints in more detail. Users can view their story efforts under the backlog tab. Clicking on the the number of tasks for a story should give them a view of the task level efforts. Users can also view the story effort for a particular sprint by clicking the number of stories link in the sprint snapshot section on the dashboard.
• No More Free Signups: Users will not be able to sign up unless they purchase a plan. A free online demo will allow users to go through ScrumEdge and see how it works. Users can take the ScrumEdge demo by clicking the “demo” button on the main page.
• Google Ads for Existing Users: Existing users with free accounts will see Google ads at the top of each page. We know this somewhat effects the user experience but we gotta make a buck too. Ads can be removed by purchasing a subscription plan.
• Community Feature Removed: We have removed the community feature from ScrumEdge. When we started we had thought this would be a good feature that would allow different Scrum teams interact and discuss their scrum related problems and achievements. However, this idea never caught on and very few teams were actually using the feature.