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.

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.

The Underpowered Product Owner

A project with an underpowered product owner is much like a car with an underpowered engine: The car runs, but it struggles when the going gets tough. An underpowered product owner lacks empowerment. There may be several causes: The product owner does not have enough management attention; the sponsorship comes from the wrong level or the wrong person; management does not fully trust the product owner or finds it difficult to delegate decision-making authority. As a consequence, the product owner struggles to do an effective job, for instance, to align the Scrum team, stakeholders, and customers or to exclude requirements from the release. A product owner of a new-product development project I worked with, for instance, had to consult his boss, the head of the line of business, for every major decision. Not surprisingly, this caused delays and eroded the team’s confidence in the product owner. Ensure that the product owner is fully empowered and receives support and trust from the right person.

The Overworked Product Owner

Being overworked is not just unhealthy and unsustainable on a personal level; overworked product owners quickly become bottlenecks and limit the project’s progress. Symptoms of an overworked product owner include neglecting product backlog grooming, missing sprint planning or review meetings, and not being available for questions or giving answers only after a long delay. Overworked product owners are at odds with the Agile Manifesto’s concept of sustainable pace. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

There are two main causes of product owner overburden: not enough time to perform the role and not enough support from the team. Availability tends to be an issue when the product owner role is just one of many jobs competing for time and attention or when the product owner looks after too many products or teams. Not enough support from the team is rooted in a wrong understanding of product ownership: Even though there is one product owner, most of the product owner work is carried out collaboratively. The team and ScrumMaster must support the product owner.

To avoid an overworked product owner, try the following: First, free the individual from all other responsibilities. Start with the assumption that being a product owner is a full-time job, and that one product owner can look after only one product and one team. Second, ensure that the team makes time in every sprint to collaborate with the product owner. Scrum allocates up to 10% of the team’s capacity in every sprint for supporting the product owner (Schwaber 2007). Not only does collaboration spread the work across many shoulders; it also leverages the team’s collective knowledge and creativity.

The Partial Product Owner

Some organizations split the product owner role and distribute its duties across several people, for instance, by employing a product manager and a “product owner.” The product manager takes care of the product marketing and product management aspects, owns the vision, is outward-facing, and keeps in touch with the market. The “product owner” is inward-facing, drives the sprints, and works with the team. In these cases, the so-called product owner is little more than a product backlog item writer. This approach reinforces old barriers, blurs responsibility and authority, and causes handoffs, delays, and other waste.

Instead of splitting the product owner role, organizations should face the challenge of applying the role properly. One person should be in charge of the strategic and the tactical product management aspects. This may well require organizational changes, including adapting job roles and career paths and developing individuals to take on a rich set of responsibilities.

The Distant Product Owner

A distant product owner works separately from the team. Distance may evoke images of a globalized world with the product owner on one continent and the team on another. But distance comes in many forms and degrees. It starts with working on the same site in different rooms, and it ends with product owner and team being separated across continents and time zones. I have found recurring issues with distant product owners, including mistrust, miscommunication, misalignment, and slow progress. There is a reason: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Avoid distant product owners by colocating all Scrum team members. As mentioned earlier, mobile.de experienced a significant productivity and morale increase after colocating its product owner, ScrumMaster, and team. If colocation is not an option, the product owner should spend as much time as possible in the same room as the rest of the Scrum team. Remote product owners should be on-site at least for the sprint planning, the review, and the retrospective meetings. Moving from a distant to a colocated product owner often takes time. It may require hiring and training a local product owner. In some cases, it may also require rethinking the company’s product strategy, including where the company develops its products.

The Proxy Product Owner

A proxy product owner is a person acting as a placeholder for the actual product owner . I have found proxy product owners used to compensate for overworked, partial, and distant product owners. At a client of mine, the vice president of product management was asked to take on the product owner role for a business-critical product. Even though he was ideally suited for the job, he struggled to spend enough time with the team. The business analyst on the team consequently stood in as a proxy product owner when the real product owner could not be there. The proxy did most of the product owner work without being empowered. The actual product owner ultimately decided about product backlog prioritization, release planning, and whether to accept or reject work results. What followed was an increase in conflicts and miscommunication, a slowdown in decision making, and a decrease in productivity and morale.

Using a proxy product owner is an attempt to superficially treat a systemic issue. Rather than employing a quick fix, organizations should address the underlying issues. This might require freeing up the product owner from other obligations; colocating the product owner, ScrumMaster, and team; or even finding a new product owner.

The Product Owner Committee

A product owner committee is a group of product owners without anyone in charge of the overall product. There is no one person guiding the group, helping to create a common goal, and facilitating decision making. A product owner committee is in danger of getting caught in endless meetings with conflicting interests and politics—something also referred to as “death by committee.” No real progress is achieved; people stop collaborating and start fighting each other. Always ensure that there is one person in charge of the product, an overall or chief product owner who guides the other product owners and facilitates decision making, including product backlog prioritization and release planning.

Summary

Applying the product owner role effectively is not only key to developing successful products with Scrum. It is also a learning process for the individuals playing the role and for the organization. As making mistakes is part of that process, don’t expect to apply the role perfectly from day one. But watch out for the traps discussed above. Ensure that there is always one product owner responsible for each product in your organization. (If more than one product owner is required, use a product owner hierarchy with a chief product owner in charge of the entire product.) Make sure your product owners are empowered, have a realistic workload, and can work with their teams onsite. This will allow you to apply the role effectively thereby increasing the likelihood of developing successful products.

By Mike Cohn

I’m a strong proponent of using metrics. They can help us understand how our projects are progressing and how well our software development process is working. I am not a believer, however, in the old adage that we cannot manage what we cannot measure. As Robert Glass pointed out in his book Facts and Fallacies of Software Engineering, we manage what we cannot measure all the time. He gives the example of cancer research. I am sure that cancer researchers manage their work and that they themselves are managed. Yet no one can draw a Scrum-style burndown chart or calculate earned value toward discovering a cure.

I was recently in Las Vegas for the annual Better Software Conference & EXPO. One of the things I learned while there was that casinos have installed monitors at the roulette tables that show the results of the last twenty or so spins of the wheel. The casino's idea was that if they could show that the last four spins of wheel had come up red then gamblers would decide that black was due. Or gamblers would decide that red would continue its streak. The casino would win either way as more money was bet.

A metric such as the results of the last twenty spins of a roulette wheel is enticing. It seems like it should be useful, and it can be presented in a visually appealing manner. Indeed, the casinos display each of the last results in either red or black with results of each number offset to different sides of a display. This makes it easy to see at a glance the relative number of red and black results, as well as any current "trend."

Ultimately, however, this is a useless metric. Each spin of a roulette wheel is independent. Red’s having shown up four (or four hundred) consecutive times has no influence on the next spin of the wheel. Most gamblers are smart enough to know this, yet roulette betting is up 30 percent since use of this metric began.

If we can be misled by a metric as obviously flawed as this one, think how far astray some more complicated project metrics may lead us. As an example, consider a team that wishes to measure the rate at which testers are discovering defects in a product that is nearing its release date. Presumably this team will experience a decrease in the rate of defect discovery as the application improves. If the team decides to report hourly on defect discovery data, managers will see a definite drop during the lunch hours when fewer testers are working. They could then misinterpret this to represent an improvement in the application. More realistically, the team could measure at the daily level, in which case they’ll see misleading improvements whenever testers take a day off.

In devising or considering metrics for your project, keep in mind these guidelines:

• Measure only what can be measured. I’ve come across a number of metrics lately that attempt to measure the business value delivered by each small feature added to a project. If the features are too small, measuring the value contributed by each doesn’t work. For example, what is the value of adding delete key support to a word processor?
• Measure at the correct level and in the correct units. Measuring the number of defects discovered per hour can be misleading because vastly different amounts of testing occur during different time periods. A better metric would be the number of defects discovered per hour of actual testing time.
• Measure something only if you plan to act on the results. There is a cost to collecting metrics. Don’t incur these costs unless you plan to act on the data.

Metrics can be a very useful tool on a project. Choose yours wisely—and remember that it is possible to manage some aspects of a project without metrics.

By Mike Cohn

User stories have become an increasingly popular way for agile teams to express requirements. Teams like that working with user stories shifts the emphasis from writing about requirements to talking about them. Project customers like that they are not expected to do the impossible and identify all needs upfront. Users of a product built with user stories like that the product is more likely to meet their needs than one built using a requirements technique more focused on writing than talking.

However, even though user stories cause teams and customers to talk more, there is often much still that needs to be written. Contract or outsourced development is one situation in which a team will need to augment conversations with documentation. This article will show one technique I’ve used for writing contracts to cover contracted agile development.

A few years ago I worked on a system intended for use by broadcasters during the summer Olympics. Sportscasters, writers, and others would use the system to dredge up facts about competitors in the various events. A sample scenario was that a sportscaster who would be covering the 400-meter hurdles later in the day would use this system to research past performance and find interesting personal facts to interject into the commentary. The system was designed as a large web of information: a user could, for example, start with the event (400-meter hurdles) and drill down from country to athlete. Or starting with an athlete a user could navigate to all events that athlete would compete in and then to another athlete in one of those events, and so on. This application was outsourced to my team which developed it using Scrum, one of the most popular agile processes

Requirements were written as user stories using this template:

As a <type of user>, I want <some goal> [so that <some reason>].

This template allows user stories to clearly identify the user who wants to accomplish something, what it is that she wants to accomplish, and optionally why. There were a handful of user types on this system but for this example we only need to know about two of them: viewers and content providers. A viewer was any user who was primarily looking at data in the system. This includes the sportscasters and researchers discussed earlier. Content providers were the writers who put all of the data into the system in advance of its use. Some of the stories identified for this system were:

1. As a viewer I can view details about a specific athlete.
2. As a viewer viewing an athlete, I can easily navigate to the events he’s in and a list of other athletes on his team.
3. As a viewer I can bookmark athletes of interest.
4. As a viewer I can easily return to athletes I’ve bookmarked.
5. As a viewer I can highlight portions of an athlete’s profile so that when I next view the profile I can see items of most interest to me.
6. As a content provider, I can have basic formatting control over how information is displayed.

It would have been challenging and risky for us to estimate work based solely on these user stories and then to commit to a fixed price contract. We needed more information, which we could get through conversations with our customer. But we also needed to document some key assumptions and decisions that would result from those conversations. What we did was identify a small number of high level acceptance criteria for each user story. Today I refer to these as conditions of satisfaction for the story. We then produced a requirements documents that included each user story along with its conditions of satisfaction. Here’s how the first story above was augmented with its conditions of satisfaction:

1. As a viewer I can view details about a specific athlete.

• Name (multiple, could be long, include pronunciation)
• Nickname (include pronunciation)
• Prior performance at Olympics
• World and Olympic records held
• Interesting anecdotes
• Citizenship, where trained, coach (link)

6. As a content provider I can have basic formatting control over how information is displayed.

• Italics
• Bold
• Bulleted and numbered lists
• Not WYSIWYG but can click a button to see a preview

The conversations that led the team to this list were held before the contract was written and before coding began. Discussions of story #6 were particularly important because the team was able to rule out the WYSIWYG (What You See Is What You Get) editor and save the customer money with a preview button instead. They also determined that very simple formatting was all that was required. Font styles, sizes, and colors, for example, were not needed. This helped avoid a potential conflict that could have resulted in a money-losing low bid or an unnecessarily high bid for the project that the customer would have rejected.

Sometimes a user story that appears very straightforward hides some very risky assumptions. Discussing the conditions of satisfaction can help identify these assumptions so that the developer and customer can be more confident that they are in agreement and that the contract covers the work expected. An example of this can be seen in this user story:

5. As a user I can highlight portions of an athlete’s profile so that when I next view the profile I can see items of most interest to me.

At first glance this story seemed clear. The developers were planning an interface that would allow a viewer to select a yellow highlighting marker tool and indicate as many regions as desired. However, our conversations with the customer pointed to more work than that. Like all of our discussions to flesh out details of a user story we asked the customer questions like:

• How will we know we’re done?
• When we demo this story to you what would you like to see so that you know we’ve done what you expect?

This led to a discussion of requirements that the customer hadn’t even thought about. Some of the highlights should work precisely as we’d planned, but now the customer also wanted “global highlights” made by one user but visible to all. This led to a discussion of security privileges (should all users see all highlights?) and other topics. In the end we settled on a yellow highlighter tool for private highlights and a blue tool for global highlights. The story and its conditions of satisfaction appeared in our contract as:

5. As a user I can highlight portions of an athlete’s profile so that when I next view the profile I can see items of most interest to me.

• Two types of highlighting—yellow (private) and blue (global)
• Highlights made during one session are visible in later sessions

Naturally, collecting these conditions of satisfaction can be time-consuming. This is somewhat mitigated by the fact that we are not trying to drive every bit of uncertainty from the requirements as that would be impossible. Instead, we’re trying to drive out sufficient uncertainty that each party to the contract can feel comfortable with the amount of risk being assumed. In my experience taking user stories down to the level of conditions of satisfaction is often useful on the first contract between a developer and customer. For subsequent projects—if the two have learned how to work together and have established a level of trust—contracts may only need to include the user stories.

Of course, there’s more to writing a good contract for an agile project than just including conditions of satisfaction for the user stories. A good contract will also align incentives between the parties. Additionally, the team must have a good approach to estimating that provides a high likelihood of a profitable project. Starting with user stories augmented with their conditions of satisfaction, however, is a good start.

By Mike Cohn

The concepts of agility and project governance are not fundamentally opposed. Each is an attempt to improve the finished product. Scrum strives to do this through close collaboration and the short inspect-and-adapt cycles of the timeboxed sprints. Project governance strives to do it by what we might call inspect-and-approve (or reject) checkpoints in which the product or project is compared to a set of desirable attributes.

However, while pursuing similar goals, Scrum and project governance take entirely different routes to achieving those goals. It is in these different routes where problems will arise in mixing the two. Fortunately, a few compromises on each side, combined with the following actions, can lead to a successful combination of agility and oversight.

Negotiate and set expectations up front. Undoubtedly, the first Scrum project to go through the governance process in your company will have challenges. There will almost certainly be some things they cannot do; for example, a Scrum team cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better. The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.

Fit your reporting to current expectations. The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint. Don't fight these expectations. If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information. If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing the number of times the build server kicked off continuously integrated builds and the thousands (or perhaps tens or hundreds of thousands) of test runs that were executed.

Invite them into your process. Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular meetings they will hold. I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project. The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.

Reference a success. Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through.

It's one thing to look at agile software development in a test tube; it's another to experience it in the real world. In the test tube, agile methodologies like Scrum are easily adopted by all members, and the nasty realities of corporate politics, economics, and such cannot intrude. In the real world, though, all of these unpleasant issues do exist. It is rarely as simple as deciding to use Scrum and then being able to do so with no other constraints.

Because few organizations will go so far initially as to completely revamp their current approaches to governance, teams need to work with their organization's non-agile governance. Adopting an attitude of compromise and taking the actions outlined above will go a long way towards easing those first Scrum projects through the gates.

By Mike Cohn

Agile processes replace some of the upfront planning of a traditional process with a just-in-time approach in which plans are progressively refined. For the often-used example of a team working in isolation, progressive refinement usually takes the form of creating a high-level release plan and then planning each iteration as it starts. While this is often sufficient for the lone team working on a desert island, it will generally be inadequate on a project being built by multiple teams. When a team needs to integrate its work with the work of other teams, all teams involved will usually benefit from what is known as rolling lookahead planning.

A team doing rolling lookahead planning will begin its iteration planning meetings just like any other team. Usually this is by doing commitment-driven iteration planning, which takes most teams two to five hours to plan a two- to four-week iteration. This is because commitment-driven iteration planning requires the team to determine which product backlog items it will commit to deliver during the iteration by carefully considering each. Product backlog items are discussed and considered in roughly the priority order established by the product owner or customer. The tasks necessary to complete a product backlog item are identified and estimated. When the team finishes discussing the work involved to complete a product backlog item, team members decide whether they can commit to completing it in the coming iteration.

Once the current iteration has been planned, the team remains in the iteration planning meeting and plans two more iterations. Wait, before you panic let me point out that while it often takes two to five hours to plan the first iteration, this is because the second and third iterations are planned at the user story or product backlog item level rather than with tasks as was done with commitment-driven iteration planning for the current iteration. Using data such as its historical average velocity, or a projection of future velocity if there’s a good reason to deviate from history, the product owner and team identify the product backlog items that are likely to be developed in the next two or so iterations.

The team is not committing to deliver these more distant items in the same way it is committing to complete the product backlog items of the current iteration. Specific commitments will be made to those iterations when each rolls forward to become the current iteration. Until then, each is planned only at a high level and only by identifying the work likely to be done in each iteration.

A team does not perform rolling lookahead planning to identify design considerations for the current iteration, although that may occur and be a side-benefit. The chief purpose of rolling lookahead planning is the coordination of work to be done by multiple teams. As new iterations roll into the planning horizon, teams look ahead to the functionality likely to be developed in those iterations. In doing so, teams on a large project are likely to find dependencies upon one another.

For example, suppose both your team and mine are ready to plan the fourth iteration of what will be a seven-month project. We conduct separate meetings, committing to features to be developed in iteration four. We separately identify and estimate the tasks to be performed in that iteration. Before concluding our separate meetings, our teams each use historical velocities to forecast what they will do in iterations five and six.

After both iteration planning meetings are over, you tell me that your team has identified a dependency on my team. You need me to develop something and pass it along to you so that you can complete a particular product backlog item. I tell you that my team cannot do it during iteration four as we just finished planning that iteration. That’s fine with you because you don’t need it until iteration six as it just now rolled into view. We agree that my team will develop the requested functionality in iteration five, delivering it to you at the start of iteration six. By looking ahead two iterations we have successfully avoided the emergency of "my team needs this from you this iteration" that can otherwise be common on large agile projects.

Rolling lookahead planning, and specifically looking ahead two iterations, is a useful technique that belongs in the toolbox of any agile team working on a large project.

By Paul Given

I recently worked as the project leader (ScrumMaster) on a project trying to transform its ongoing work stream. Historically, our teams were structured very tightly along roles in a typical waterfall fashion. We produced two software releases a year that aligned with major releases of software from partner financial associations. These two releases spanned up to twelve different systems and development teams. The releases had hard dates. Requirements and test data trickled in and changed until thirty days prior to the go live date. These last minute changes and difficulty in managing the test environments were causing tremendous spikes in hours expended at the end of our projects. Something had to change.

Our situation

Our workstream was full of repetitions and disconnects that contributed to our time crunch issues. The project lifecycle usually began when the business systems analyst (BSA) received documents from a partner financial association. The BSA would review these documents with the business customer to create business requirements. The BSA would then review the business requirements with the design leads to create systems requirements.

In turn, the design leads would create both high-level and detailed designs. The developers would subsequently develop and write unit tests according to the detailed design. The design lead would trace the unit tests to the design, and then trace the design to the system requirements. The BSA would trace system requirements to business requirements, and then trace business requirements to the association documents.

Meanwhile, the testing team would write system and end-to-end test cases. The testing team would trace test cases back to system requirements and then to business requirements. Eventually, the developer would turn his code over to testing.

Without fail, two weeks before go live, a tester would find an issue—and no one would know how to follow the tracing to determine the cause of the issue. There would be a mad scramble to fix the problem, hence the spike in hours. Meanwhile, our business customers couldn’t validate results because they had not had any contact with the project since the BSA reviewed requirements with them. All along the way, the project manager hounded everybody for document approvals.

Solution

You can see why we needed to try something different, something leaner. We scrapped our old process and applied Scrum. During the first thirty days of the project we completed the following tasks:

1. Reviewed documents from the financial associations as a team (two BSAs, seven design leads, three test leads, and three customers)
2. Developed the system requirements as a team and integrated these requirements into the association documents.
3. Built a systems testing environment and an end-to-end testing environment.
4. Using the system requirements (and eliminating the high-level and detailed designs), we defined the necessary changes to system interfaces, built the stubbed/shell version of the systems interfaces, and released them to the system test environment.

After the first thirty days, we divided the remaining system requirements into four sets of iterations. An iteration was considered “done” when the code was turned over to the systems and end-to-end test environments.

Outcome

The work was finished and systems testing completed forty-five to sixty days prior to the release, at a sustainable pace and with a high quality.

At that point, the associations announced a significant interface change. Still using Scrum, the teams handled the interface change, the associated business functions, and the testing in thirty days and were ready to go when test data was available from the associations.

Analysis

The Scrum process we instituted worked well. Several factors contributed to our success: team collaboration, multi-level Scrum, and visual tools.

While the teams were not co-located, we were able to accomplish team collaboration through twice-weekly Scrums between the teams. We let teams manage their own work (some offshore, some in-house, some vendor-supplied changes). We set aside time for inter-team issues twice a week. Because they were continually asked to validate functions in the end-to-end test environment, the business customer was engaged throughout the process, which helped eliminate any unnecessary work.

The team collaboration also helped engage technical resources into the requirements gathering process early. This involvement eliminated the need for all of the effort we used to expend on tracing requirements to everything else. The team was engaged in the goals and needs of the business, allowing them to offer solutions to how to get features done easily. Finally, the impacts of any changes were better understood by all.

Another key factor in our success was multi-level Scrum. Specifically, defining the interfaces by which a team could work “behind” allowing teams to work independently. This ability helped eliminate the tension between “decide as late as possible” and “define it and build it as quickly as possible.” Multi-level scrums also allowed the business to be on call for issues providing insight without having to be present 100 percent of the time.

The final key factor in our success was our use of Scrum’s visual tools. We used burndown charts to show the feature milestones being produced (with our common definition of “done”). These charts showed a sustainable but focused effort. The test status dashboards were helpful in giving business a good indicator of quality and progress.

Of course, as in all endeavors, there is still room for improvement. We’d like to move to daily Scrums. We need to find a way to link the offshore and vendor system to the iterative process to generate less confusion on who is doing what in which sprint/iteration. We should create even more transparency by increasing our use of visual tools by individual teams. Finally, we want to find a way to better use automated tests. Doing this would allow testing to be repeated easily and avoid timely regression testing with each sprint/iteration.

Overall, though, we have found that Scrum worked well—even in a fixed-date, fluid requirement environment like ours.

By Pat Guariglia

The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.

The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.

The problem started when someone in my organization’s executive management, “Jeff,” took notice of the burndown charts hanging around our project area. Jeff started to review the charts and drew his own conclusions. As he saw it, the burndown seemed like a good way for the team to drop scope at will, without regard for what it did to project dates and costs.

I was unaware of Jeff’s misinterpretation until I gave a quarterly project briefing to executive management. During the briefing, he asked me to explain the burndown chart. I described how the product owner and team move stories out of the sprint if the chart shows us trending above our planned progress line. Conversely I explained how stories could be moved into the sprint when the chart is trending below the progress line.

Jeff explained that while he understood the need to move stories and tasks in and out of a sprint, he didn’t have a warm and cozy feeling about how those actions affected the cost and time for the project. He asked questions such as, "What happens to the duration of the project if something in the current sprint takes longer than you planned and you need to move something out?" and "What happens to the cost of the project if something gets moved out?” Although I was able to answer these questions during the meeting, I realized that I needed to do a better job of giving upper management a picture of the whole project. I decided to start using release burndown charts, which provide a view of the progress of releases throughout the project.

Scrum teams can often get away with a somewhat myopic, or nearsighted, view of their sprints and releases. After all, teams are rightly focused on delivering the functionality in the current sprint. Their metrics, therefore, are also focused on the current iteration. A sprint burndown focuses solely on the current sprint and illustrates progress along an expected path for that time box (as shown in the figure below). At the start of each sprint, the team plans to tackle a subset of the entire project’s user stories. This subset of user stories has an associated story point value. Teams use sprint burndowns for various reasons. They may want to see how much time and work is left in the sprint. Sprint burndowns also help the team understand whether or not stories are at risk within that sprint. If stories are at risk, the sprint burndown may be an indicator that stories should be removed. If progress is greater than anticipated, the burndown chart can be an indicator that stories may need to be added to the sprint.

On the other hand, sponsors, stakeholders, and other members of management who fund the project need to move beyond that myopic view and look at the big picture. They need to have answers to the following questions: How well is the project funded? How much money is left? When will it be completed? What value is being delivered and when? The release burndown provides a more complete picture of value and time. In the figure below, the entire project consists of 750 story points. The team’s velocity (the amount of product backlog a team can handle in each sprint) is 75 story points. The team estimates it will take 10 sprints to complete the work (750 total story points / 75 points per sprint = 10 sprints). Therefore, the release burndown shows ten release bars extending across the chart from left to right. The vertical axis shows show the number of story points. As value is delivered over the course of the project, the story points (shown in a blue bar in the figure below) burndown; as scope is added or as  estimates increase, the story points increase as well (as shown by the red bars in the figure below). The trendline shows how the project is trending overall. Release burndowns provide the overall project status and the value delivered to date for each release or sprint.

A release burndown shows, at a glance, all of the project’s sprints and their cumulative effect on the project. Release burndowns allow you to visualize the overall project timeline and calculate total project costs, assuming you know approximately how much each sprint costs. A simplistic example would be as follows: Ten sprints, at a cost of $10,000 each, would equal $100,000 for the complete project. If you add an extra sprint, the project cost goes up by approximately $10,000. Management can also see from a release burndown chart when extra sprints were added because remaining work has been re-estimated or work has been added. They can also see the affect of other factors (such as changes in the team’s velocity or membership) on the long-term project outlook.

Product owners can use release burndowns to take corrective scope action when they see the overall progress line trending in the wrong direction. If they see the team is progressing faster than planned, the project may end earlier or they may have the option of pulling in lower priority work from the backlog. If they see the team is not completing as much as planned in each sprint, the product owner may opt to de-scope some of the project, re-prioritize the backlog, or look to project sponsors to increase the length of the project or add project resources.

Release burndowns are an important tool for communicating the condition of the project, the long-term team velocity, and delivered value. In contrast, the sprint burndown is not intended as a long-term project information radiator; a single sprint burndown can't show you what happens to the project when you move work out of a sprint or re-estimate. A tool like the release burndown is much better suited for this level of communication.

Now that I've been using release burndowns for a while, it's hard for me to imagine running a project without one. What about you? Are you using release burndowns?

Planning Poker is a process used for estimation during the Sprint planning meeting, many times with actual cards rather than software. The various team members do their estimation of the tasks using Fibonacci numbering sequence, and after a couple of rounds of discussion, a finalization of the estimates are done, and these are converted into Sprint Backlog. However, for teams that are not very comfortable with Planning Poker, there can be several problems as dealing with Planning Poker. Some of these are:

• For somebody who is not comfortable dealing with Planning Poker, the concept of providing estimates in this manner can be confusing to people. Guidance, simulation and some hand-holding during early stages is essential
• There can be ego clashes if the estimates provided by team members vary widely, with the senior team members not being very comfortable if the estimates provided by the more junior ones are accepted. This needs careful handling
• Once numbers are presented in the meeting, then non-team members (including the product owner and senior stakeholders) will accept these numbers, and any further refinements start getting compared against these numbers
• Once somebody sees a number by somebody else, they start getting doubts over their numbers and if given a chance, many of the team members are willing to modify their numbers (just by doing some modifications in their head over the estimation). This can sometimes lead to a quick firming of the estimates towards a more accurate number, but can also lead to a herd mentality behavior
• Planning Poker is hard to do when the team is distributed, and needs more careful planning in terms of logistical coordination
• In Planning Poker, the assumption is that the team member has the required level of knowledge, but this can be inaccurate, what can happen in many cases is that the team has as much knowledge as is available, but there are many blank areas that are not yet filled, whether these be requirements from the product owner, or dependencies that are not known
• In some cases, the Product Owner is not satisfied by the varying estimates, and may want to put pressure to select the lower estimate so as to get more features in the current Sprint. The ScrumMaster needs to be pretty vigilant to avoid these scenarios

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. 

A Creative Solution

I was elected as the ScrumMaster.  My job was to guide the team through the framework, facilitate our meetings, keep the team focused on the goal, and remove any impediments standing in our way.  We selected the functional manager as the product owner, our primary interface with the other stakeholders.  We created a product backlog, using the list of work items as epics and categorizing the stories appropriately.  We ranked the priority and voted on the complexity of the stories.  With the limited availability of our team, we could only work on very small chunks of work within a sprint.

Our success with Scrum was directly tied to the team’s commitment and buy-in to the framework from the beginning.  Those that were new to Scrum listened to the overview of the artifacts, roles, and ceremonies, and eagerly applied the practices to the work to be accomplished.  As a result, project overhead was reduced and the team began producing results immediately.  In the coming sprints, the team was able to collaborate more effectively, giving them the time they needed to maintain their existing workloads.

Something to Prove

Meanwhile, the people who were working in the role that we were redefining had little confidence in the announcement of a new guidance team.  Although they had been promised changes by previous "strategy teams" the end results were not always seen or had little value.  Our team was able to build trust with this community by sharing our backlog and deliverables in a collaborative online environment.  This transparency enabled our team to provide a forum for iterative and incremental feedback.

Our team went further into engaging the input of these and other stakeholders.  It was apparent that we neeeded to gain buy-in in a short amount of time.  I introduced the team to Open Space, a meeting format in which a theme replaces the traditional agenda and the participants identify the topics for discussion.  Using Open Space, we asked the people what they wanted to talk about and enabled them to self-organize and discuss the topics that were important to them.  The greatest benefit from our use of Open Space was the involvement from the people that attended.  Our team was then able to get input on many items in the product backlog from the entire community while also gaining their buy-in and understanding the root of any issues.  While many of the backlog items were completed within the Open Space session, we also added new stories as a result of the discussions, helping us to avoid critical oversights.  By engaging the community in such an open way, we not only were able to greatly increase our velocity in a given sprint, but also were able to uncover additional ways we could enhance the role and truly deliver value as a team.

Space to Work

The product owner asked me to explain our approach and review the backlog with other stakeholders, including high-level managers.  The backlog prioritization received a lot of scrutiny.  The stakeholders had many questions as to why certain items were chosen for the current sprint over others they felt were higher priority.  Their questions gave me an opportunity to explain the Scrum framework.  I discussed planning and complexity size. I talked about how we worked with the product owner to deterimine our priority and took into account work for future sprints through release planning.  I explained the need to bring in only one or two high complexity stories per sprint and how we broke large stories into smaller deliverables.  Given our team's velocity, some lower-complexity stories were often brought in to help round out the sprint with what we could accomplish to achieve some quick wins.

After explaining the rationale behind backlog prioritization and sprint selection, management and the other stakeholders trusted the team’s approach and allowed us to continue working without interruption.  The Scrum framework worked as designed, protecting the team, the work in progress, and ultimately the project’s overall integrity.

A Clear View Changes Perspectives

Another benefit of our approach and backlog overview was that it gave management insight into how much work we could take on during a sprint’s timeframe and still fulfill our other work commitments.  Had the other managers been able to interject new work mid-sprint based on their own prioritization schedules, the team would not have been able to deliver and would have accumulated multiple work in progress activities without completing any of them.  By displaying the work priorities in the backlog and communicating the timing of the sprints, we were able to project which work items could begin in the next sprint without interrupting the current sprint.  The framework provided a means of having a single source for prioritization.  It is not always easy to tell a manager, "no," but when you can explain the framework you are using to complete the work and provide them a controlled mechanism to provide input to the work, they will have a way to navigate work priorities without disrupting the team.

Scrum Just Fit

This was a small team of people in a large corporate arena.  Our ability to adopt the framework and willingness to try something innovative is how this project got “done” in spite of the constraints that come with large enterprise.  The product owner quickly picked up on his role and was very engaged.  The team self-organized, took on the work we could, and consistently completed the work we set out to do.  Our managers understood what we were doing and left us alone to do it, meanwhile still having input into future tasks.  We gave our customers the ability to communicate their concerns and opinions through collaborative tools and open space activities, a key factor in our success. 

We pulled off the near impossible, moving from a challenge with countless limitations to a valuable end result.  We credit Scrum's simple framework for enabling our high productivity.  Through self-organization and collective incremental delivery, we built momentum that translated into real value.  Our experiment, born of necessity, was a true success and is a model that other projects can follow.  While we can’t change the whole business all at once, we can inspect, adapt, and start the transformation one opportunity at a time.

By Tirthankar Barari

Most new ScrumMasters have a basic understanding of their new role. Many have been through training and received their Certified ScrumMaster designation. When their teams ask them to step in as ScrumMaster, they are often excited and eager.

But after the initial exuberance fades, a nagging doubt begins to form. Each day, while the ScrumMaster is listening to and facilitating the daily standups, a quiet thought begins to circulate in his mind:

The last day of my first Sprint is approaching soon. Are we going to deliver all the items we promised? What exactly do we demo, anyway? What if the thing crashes during the demo? Are we overlooking something? Did we misunderstand the requirements? Does the estimate of work remaining truly reflect reality? What if we hit a snag? Are we missing or overlooking any impediments?

Sound familiar?

If you are a first-time ScrumMaster it’s normal to have all of these concerns. Honestly, the more questions you have, the better. After all, while searching for the answers, chances are you will resolve issues before they bust, rather than after. From my own experience as a first-time ScrumMaster for a development team moving from a traditional software development process to Scrum, I have compiled a list of things you need to keep an eye on, almost all the time, during your sprints.

Bite off only what you can chew

During the sprint planning phase, as the team is committing to backlog items, help them question whether or not they can truly cover all the items. Typically, during planning, development team members have at least some tasks and items they know they will be working on. Individual team members will often know when they are being overloaded, but your job is to be an extra set of eyes. Make sure no one person is taking on too much and that the overall workload seems feasible. Ask questions and challenge assumptions. Bringing potential problems to light early helps mitigate the risk of over-promising and under-delivering to some extent.

You thought of apples, I gave you oranges

Many times, what the Product Owner when he wrote the user story is not at all what the UI designer or the developer understood it to be. Your job is to make sure they are all on the same page as early as possible in the sprint. As a followup to the marathon sprint planning meeting, make sure these players stay in sync and in agreement on each backlog item.

For complex backlog items or features, one of many ways to accomplish this is setup one or more mini demos along the way. These should be quick 10-to-15-minute presentations run from the workstation of the designer/architect/developer. Do not involve the whole team for this. Ideally, this mini demo should include one or two team members who have been working on the backlog item and the Product Owner. No fancy slides or preparation time. Keep it very informal. If it is difficult to get the Product Owner and others together for ten or fifteen minutes, you can accomplish something similar by circulating screen shots. The point is to keep the lines of communication open and receive feedback earlier rather than later.
Many people may have inhibitions against running mini demos, as opposed to one overarching demo at the end during review. But for large, complex features, periodic mini demos can be extremely helpful in catching discrepancies in understanding early on.

Plan to plan for the planning meeting

Issues that crop up time and time again during the Sprint Planning meeting include:

• The backlog item is not well defined, so how can we estimate?
• Is it really technically feasible?
• What is the scope of the work here? This, this and also that..? How about that other thing..?

One step that immensely helps in eliminating such drags during our planning meeting was to run a preplanning meeting. Certain things to keep in mind here.

• Do not involve the entire team in this meeting
• Try to schedule it as many days prior to the beginning of the next sprint as possible
• Include the Product Owner and some members of the team who might have more insight or prior knowledge on the features to be discussed

At the end of this meeting, the Product Owner should have shared many more specific details about the backlog items destined for the next sprint. These details should be captured and recorded so that when those inevitable questions about the scope of the work pop-up during effort estimation time, the answers are already there.

What we say standing up is what we do sitting down

Stress to the team that their fellow team members are depending on them to follow-through on what they commit to during the daily standup, and help them in their efforts to do that. I do not mean to imply that you should police or micromanage the team on what they do once they leave the daily standup. On the contrary, the team should manage itself. Team members will and should hold each other accountable to their public commitments.

So where do you come in? At times, team members become victims of external forces. They are pulled off to work on something else in parallel, or asked to start on something “more important.” It is your job to ensure that such distractions do not jeopardize the delivery of your sprint outputs. Other impediments can also stand in the way of delivery: maybe the machines are not in yet or the software or tools needed by development haven’t arrived yet. Sometimes the team members are shy or uncomfortable about bringing these kinds of impediments up during the daily standup meetings. Look for opportunities to encourage them to mention these obstacles. Once they do, help resolve them.

Plan the demo and demo the plan

If you happen to be the ScrumMaster of a team that is ushering in agile to the organization, your sprint plannings, standups, reviews, and retrospectives could garner interest and attention from many quarters. You may even have distinguished members of the organization sit in such activities occasionally. This is definitely good news, an indication that the organization is taking this new approach seriously. At the same time, though, it puts a little extra pressure on you to have your meetings, and especially your demo, go smoothly.
Just as actors have rehearsals before a performance, your team may need to practice before the live demo. Planning and rehearsing the demo would also help to uncover problems before they happen in front of a live audience.

Clearly, a rehearsal would be nice, but you do not want to spend much of the team’s valuable time on just this activity. They are busy executing the tasks in the backlog, right? So, spend some of your own time chalking out a plan for the demo. You have the backlog items already. Arrange them in a sequence you thing fit. Help setup a demo machine yourself, if need be. Then let the team members for each backlog item decide who will demo that feature. Since the members of a backlog item know the feature the best, they would hardly need any more time to prepare for the demo. You need to keep control on the sequence of the demo, the setup and the support. We have found a short plan that shows the list to be demonstrated and a quick meeting the day before the demo makes the review session a reasonably smooth sail. Also, keep backup plans, in case something fails at the eleventh hour (the “demo effect”).

Think end-to-end from beginning to end

Often during a sprint, all the individuals on the team are too focused on the immediate tasks in hand. There could be many interdependencies among features within your own team’s backlog items or with features from other Scrum teams. Issues related to these interdependencies may often get overlooked during the daily standup meetings or the scrum of scrum meetings.

It is vital for more complex system development that you (or another designee or even an end-to-end team for very large systems) keep track of these interdependencies along the way. It would serve you no good to learn on the last day of the sprint that a feature from team A needed a parameter to be passed by a feature from team B and it is not done yet. Many times, team B may not even be aware of the need, while it was quite obvious to team A. One way to bring these issues to the surface early on could be to visit and revisit the system flow in mini end-to-end review sessions (even by acting out the roles)

The organization is not for Scrum. Scrum is for the organization

Are we doing 100 percent Scrum 100 percent of the time? After all, according to line 7 of page 17 of this book from that author, we should complete this meeting within 3 hours, else we are violating the rules of Scrum. How many times have you, as the ScrumMaster, faced these questions, particularly during the early stages? Wish you had a scale to measure your ”Scrumness” that you could display on top of your desk or on your wiki page in real time?
Sometimes we forget the basic premise for doing Scrum. In the end, your customers will not pay the bills on how “Scrummy” you were. Certainly it is important to follow the guidelines defined in Scrum, but the ultimate goal is to deliver what you promised, within budget and on time. In that respect, Scrum is a great enabler and more of a means to an end rather than an end by itself. While you are helping your team follow the process, don’t get so caught up in the nitty-gritty details that lose sight of your organization’s goals.

By Laszlo Szalvay

When a company is ready to transition to Scrum, the first thing it will want to know is which of its projects would make the best Scrum pilot. If no one at the organization possesses the appropriate level of experience working in Scrum environments, then figuring out which project to start with can leave a team in the dark. After all, which attributes of a project make it right — or wrong — for Scrum? Unfortunately, there are no cut-and-dried requirements for a Scrum project, but there are several factors to take into account when making a decision. When choosing among a group of projects, first consider these seven questions:

1. Is there a single Product Owner dedicated to the project? Working with a single customer helps simplify communication and reduces confusion among the team.
2. Is there an experienced Scrum coach or mentor attached to the project? If the answer is yes, the team has a tremendous advantage over a Scrum team starting from scratch and learning by trial and error. An experienced Scrum practitioner can share best practices and strategies to resolve impediments with the team, helping steer the project toward success.
3. Is the whole team located in the same place? While a single location for the team won’t ensure success with Scrum, it helps a lot. When a team is able to work within the same, small vicinity, Scrum’s emphasis on communication and collaboration can be maximized. When a team is dispersed geographically, however, a Scrum tooling solution is usually required to keep a team focused.
4. Are the project’s requirements known? How well defined are they? Scrum is so well-suited to the unpredictability of software development because it gives teams the safety of a stable work cadence. That means that, while a waterfall project would require well defined requirements, Scrum projects can begin even when only the most basic requirements are known. Requirements will then be added iteratively as more requirements become known.
5. Is the team made up of cross-functional members? Unlike waterfall, Scrum teams are made up of cross-functional members (or they should be, at least). The idea is that if an entire team can perform the range of necessary skills, it is capable of executing every stage of the development work cycle. That range of skills coupled with the close-knit team’s spirit of collaboration shortens the feedback loop and helps teams expose and resolve impediments quickly.
6. Does the team have the equipment and tools it needs to complete its sprint goals? And which agile engineering practices are being employed? Having the right tools for the job may mean the difference between doing it well and not doing it at all. And while not tools, per se, engineering practices can make a big impact on how a team performs its work. I would suggest that all Scrum teams use Continuous Integration, Test Driven Development, as well as Pair Programming to help tighten up processes and enable teams to do their best.
7. Does the project have management’s attention? From a business standpoint, an ideal Scrum pilot visibly demonstrates success for senior management. For a Scrum adoption to really take hold at an organization, it needs the support of management. Choosing a pilot that will directly affect the bottom line will hold management’s attention and create a compelling illustration of Scrum’s potential.

By Laszlo Szalvay

As agile project management methods have displaced traditional approaches in the past decade, Scrum, one method of agile project management, has emerged as the most popular. As more and more companies begin to consider it as a means to improve every aspect of their development efforts as well as the lives of their employees, partners and customers, there are several factors they should consider before embarking on an agile transformation with Scrum. Quite simply, there are conditions that will make Scrum adoption virtually impossible for some organizations. What follows is a list of impediments that commonly prevent companies from successfully implementing Scrum.

1. Wrong People.
   Just like with any other organizational initiative, Scrum implementation requires excited, enthusiastic individuals to drum up support and broadcast the success of the pilot throughout the organization. For this reason, it is recommended that the members of a pilot Scrum team be selected by volunteerism, not assignment. Team members who are leery of change will undermine the pilot’s success.
2. Wrong Project.
   To illustrate Scrum’s value to management, it’s important to choose a pilot project that is highly visible and stands to make an impact on the business. If Scrum helps a team successfully manage a project with nothing to lose, chances are it won’t convince management to get behind an organization-wide rollout.
3. Wrong Time.
   Business timing is critical. If a pilot project is begun in the midst of other major changes, it may not be noticed. Because Scrum is capable of streamlining processes, reducing cycle time, and improving product quality, it may be intentionally piloted during a time of organizational upheaval. However, when that’s not the case, teams should be strategic about choosing the right time and pay close attention to political considerations.
4. Lack of Management Support.
   Perhaps more than any other factor, management support can make or break a Scrum implementation. Without an advocate at the management level, the value that developers see in Scrum may never fully translate to their superiors. But an internal champion can help explain why Scrum makes the impact it does—and couch those benefits in terms that appeal to managers.
5. Process Confusion.
   A large part of Scrum’s ability to deliver the benefits listed above is predicated on the structure of the Scrum framework. That is, Scrum is a management wrapper with few roles, meetings, and artifacts. When one of those is modified or eliminated, it undermines the entire system. Many organizations try to lessen the shock of transitioning the way they work by mixing and matching development processes, such as Scrum and Waterfall—two opposing ways of working. Unfortunately, all that achieves is compromising Scrum’s potential to realize success.
6. Engineering.
   While mixing and matching processes will certainly inhibit Scrum’s success, Scrum is actually engineering-agnostic. Still, agile engineering techniques — especially those that arose from the Extreme Programming movement — complement the Scrum framework best and are highly recommended.
7. Get Prepared.
   Scrum may be intuitive and easy to learn, but mastery over it is difficult. Actually getting everyone on a team—let alone within an entire organization—to understand and observe its processes and values can be extremely disruptive. Luckily, the rise in Scrum’s popularity means there are tons of free online resources available as well as paid Certified Scrum Trainers who can ease the transformation process through on-site coaching and public coursework.

By Laszlo Szalvay

Scrum is a lightweight project management framework that is taking over the software development industry. It has become the de facto management strategy for most IT organizations, dominating the discourse within the Project Management Office (PMO) in recent years. Although the founders of Scrum intentionally refrained from prescribing engineering practices, many Scrum teams have experienced success by pairing the framework with engineering practices from the eXtreme Programming movement (XP). Here are the top 7 engineering practices to consider when running a Scrum team.

1. Pair Programming.
   Employing a “driver/navigator” work paradigm for your software developers helps to ensure that quality standards for code remain high. In pair programming, a senior developer is typically partnered with a less experienced developer and, as described above, the senior developer “navigates,” while the junior developer “drives.” The benefits of this arrangement are huge: Junior developers can learn the ropes from a more experienced mentor; the two can brainstorm new ways of working; and the organization experiences improved employee retention, thanks to heightened morale.
2. Sustainable Pace.
   Software development is complex and hard. One of the best ways to get past burnout is to limit the number of hours your software development teams work via a working agreement. Surely, it can be a team building experience to pull an all-nighter, but these exercises should be unique and infrequent. If your company culture includes a death march work schedule strategy as policy, one good way to mitigate the employee churn or turnover is to have a strong recruiting division.
3. Coding Standards.
   Coding standards are similar to writing standards, like MLA or AP. They are agreed upon at the outset of the project, either adhering to a recognized standard or a baseline the team has developed among itself, so as to limit heartburn later.
4. Endless Refactoring.
   Refactoring is the process by which a software team improves the code’s readability, structure, design, and scalability. XP advocates refactoring as an ongoing, cyclical process, in which code is thoroughly and repeatedly re-factored.
5. Acceptance Tests.
   Performing acceptance testing in the form of UATs (User Acceptance Tests) helps the team ensure that the product it has built is in alignment with the acceptance criteria staked out by the customer. By continually comparing progress-to-date against the customer’s expectations, the team can make sure it doesn’t waste time or energy pursuing undesired functionality.
6. Unit Testing.
   Unit testing, whereby units of code are tested to see if they are fit for use, are essential to successful product development. Even if, through acceptance tests, a team determines it has built everything into the product that the customer requested, the product still has to perform flawlessly.
7. Continuous Integration.
   This XP practice leads teams to speed up the development process by decreasing integration times. There are myriad "CI" tools on the market to choose from. Pick one and then integrate early and often to expedite the development process.

By Laszlo Szalvay

One of the Scrum method’s biggest selling points is its capacity to yield hyper-performing teams. Of course, Scrum teams aren’t just your run-of-the-mill dev teams. There are certain requisites—seven of them, actually—which teams should adhere to if they’d like to see Scrum transform their group into a well-oiled machine:

1. An ideal team includes seven members, plus or minus two. According to study, small teams work together best. Once a team grows to more than nine or shrinks to smaller than five, its ability to perform well as a team is greatly diminished.
2. Teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. By creating a team composed of individuals with backgrounds in a diverse range of disciplines, a spectrum of opinions, ideas, and experiences are represented in the group. Not only does this mean that all development activities can be performed by the group, it also means that multiple perspectives will inform difficult decisions.
3. Team members should be located in the same room, called the team room. While a single location for the team won’t ensure success with Scrum, it helps a lot. When a team is able to work within the same, small vicinity, Scrum’s emphasis on communication and collaboration can be maximized.
4. If teams aren’t located in a team room, they’ll need a Scrum tooling solution. When a team is dispersed geographically, however, a Scrum tooling solution is usually required to keep a team connected. In especially fast-paced development environments, a tooling solution may be necessary for collocated teams, as well.
5. Teams negotiate work with the Product Owner. While the development team must complete the work negotiated in the sprint planning meeting, it has some say in the amount of work it takes on. The Product Owner will expect the team to take on as many story points of work as possible, within reason. (The team would reference its established velocity for previous sprints to negotiate how many story points would be reasonable.) The value of this process of negotiation is twofold. It protects the development team from becoming swamped with an unrealistic workload. It also manages the expectations of the Product Owner, who, in turn, can do the same for customers.
6. Teams self-organize. Once a team has committed to its work for the sprint, it may determine how to complete those goals autonomously. That is, provided the team’s work is satisfactorily completed by the sprint’s end, it can choose how and in what order that work is completed. This allows natural leadership to emerge from within the team and empowers teams with the freedom to confront impediments with creativity and innovation.
7. Teams’ work should meet ALL acceptance criteria. Most Scrum teams do not award partial credit. Even if 99 percent of a project is “done,” it will be rejected in the sprint review meeting if it fails to meet all the established acceptance criteria. Teams often discover the hard way that a project’s finishing touches are often the most time-consuming and labor-intensive.

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.

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.

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 ScrumMaster serves as a facilitator for both the Product Owner and the team. It’s an arduous role that demands a distinct personality type to be successful—in large part because the ScrumMaster has no management authority and may never commit to work on behalf of the team. What follows are seven basic considerations that should be at the forefront of any ScrumMaster’s mind.

1. Be a team player. The best ScrumMasters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those two reasons, traditional project managers don’t usually make great ScrumMasters.
2. Remove impediments. First and foremost, the ScrumMaster should do everything in his or her power to remove obstacles that are preventing the team from accomplishing its sprint goals. Basically, anything that distracts or inhibits the team from making progress is considered an impediment, so the challenges a ScrumMaster might work to resolve are truly infinite. When a developer’s computer dies, it’s the ScrumMaster’s job to get it back up and running—or replace it. If developers are complaining about the high temperature in the team room, the ScrumMaster must find a way to cool it down.
3. Radiate information. One of the ScrumMaster’s primary responsibilities is to radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself. These radiators may take the form of various Scrum artifacts, from backlogs to burndown charts.
4. Support the Product Owner. Just as the ScrumMaster removes impediments for the team, he or she also works to assist the Product Owner with various activities. These include communicating updates and impediments as well as assisting with backlog and release plan maintenance.
5. Facilitate creativity and empowerment for the development team. The flipside of the ScrumMaster’s mandate to remove impediments for the team is his or her charge to foster an environment where creativity and empowerment can flourish. If a team is to self-organize to meet sprint goals, it will perform up to its potential if its members feel they have the support and confidence of the ScrumMaster and Product Owner behind them.
6. Improve the team’s engineering practices and tools as needed. To fully facilitate productivity, the ScrumMaster must make sure teams have the tools and know-how they need to succeed. This might include a Scrum tool to bring distributed teams together for close collaboration or introducing a new engineering practice that can help developers improve processes.
7. Communicate, communicate, communicate. Yes, communication is integral to each of the above points, but it’s so essential that it’s worth mentioning again. Scrum’s success hinges on clear and frequent communication among all stakeholders. The ScrumMaster acts as a hub for all of that communication, ensuring that everyone—the Product Owner, the team, and various other stakeholders—are always up-to-speed.

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 ScrumMaster serves as a facilitator for both the Product Owner and the team. It’s an arduous role that demands a distinct personality type to be successful—in large part because the ScrumMaster has no management authority and may never commit to work on behalf of the team. What follows are seven basic considerations that should be at the forefront of any ScrumMaster’s mind.

1. Be a team player. The best ScrumMasters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those two reasons, traditional project managers don’t usually make great ScrumMasters.
2. Remove impediments. First and foremost, the ScrumMaster should do everything in his or her power to remove obstacles that are preventing the team from accomplishing its sprint goals. Basically, anything that distracts or inhibits the team from making progress is considered an impediment, so the challenges a ScrumMaster might work to resolve are truly infinite. When a developer’s computer dies, it’s the ScrumMaster’s job to get it back up and running—or replace it. If developers are complaining about the high temperature in the team room, the ScrumMaster must find a way to cool it down.
3. Radiate information. One of the ScrumMaster’s primary responsibilities is to radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself. These radiators may take the form of various Scrum artifacts, from backlogs to burndown charts.
4. Support the Product Owner. Just as the ScrumMaster removes impediments for the team, he or she also works to assist the Product Owner with various activities. These include communicating updates and impediments as well as assisting with backlog and release plan maintenance.
5. Facilitate creativity and empowerment for the development team. The flipside of the ScrumMaster’s mandate to remove impediments for the team is his or her charge to foster an environment where creativity and empowerment can flourish. If a team is to self-organize to meet sprint goals, it will perform up to its potential if its members feel they have the support and confidence of the ScrumMaster and Product Owner behind them.
6. Improve the team’s engineering practices and tools as needed. To fully facilitate productivity, the ScrumMaster must make sure teams have the tools and know-how they need to succeed. This might include a Scrum tool to bring distributed teams together for close collaboration or introducing a new engineering practice that can help developers improve processes.
7. Communicate, communicate, communicate. Yes, communication is integral to each of the above points, but it’s so essential that it’s worth mentioning again. Scrum’s success hinges on clear and frequent communication among all stakeholders. The ScrumMaster acts as a hub for all of that communication, ensuring that everyone—the Product Owner, the team, and various other stakeholders—are always up-to-speed.

By Tobias Mayer

Scrum began its life as one of the new Agile approaches to building software.  These days it is considered an approach that can be used to improve the world of work in a more general sense, and indeed, to change the way individuals think and interact with one another in work situations.  The full potential of Scrum has yet to be explored.

In a nutshell, Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow self-organizing teams to deliver high quality results in short time-frames. Scrum is a state of mind; it is a way of thinking that unleashes the creative spirit while remaining firmly grounded in some solid and long-respected theoretical principles, including empiricism, emergence and self-organization.

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the market place in which the software is sold or distributed.

Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design will only result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration. Self-organization works when there are clear goals and clear boundaries.

In addition to these principles Scrum relies on two core mechanisms: prioritization and timeboxing.

Prioritization simply means that some things are more important than others. This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered. Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them! Making time to prioritize, and being rigorous about it are essential to the success of Scrum.

Timeboxing is a simple mechanism for handling complexity. We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem. The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole.

Organizational Change

With Scrum, the management hierarchies of organizations tend to get leveled and development teams have a more immediate and direct contact with customers. The work environment becomes less command-and-control and more collaborative. Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years. Many companies rely on fear and money as the key motivators for their workers. This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy. Nevertheless, the concept of changing to something as radical as Scrum strikes terror into many executive and middle-management hearts.

Scrum is still at the early-adopter stage. It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces. Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces. Others – those who dare to embrace the lean, lightweight, agile approach of Scrum – stand a greater chance of surviving and prospering. For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable. A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.

By Tobias Mayer

Scrum began its life as one of the new Agile approaches to building software.  These days it is considered an approach that can be used to improve the world of work in a more general sense, and indeed, to change the way individuals think and interact with one another in work situations.  The full potential of Scrum has yet to be explored.

In a nutshell, Scrum is a simple approach to the management of complex problems, providing a framework to support innovation and allow self-organizing teams to deliver high quality results in short time-frames. Scrum is a state of mind; it is a way of thinking that unleashes the creative spirit while remaining firmly grounded in some solid and long-respected theoretical principles, including empiricism, emergence and self-organization.

Empiricism refers to the continuous inspect/adapt process that allows both workers and managers to make decisions in real time, based on actual data, and as a result respond quickly to ever-changing conditions in the surrounding environment, most importantly the market place in which the software is sold or distributed.

Emergence results from an empirical approach. It implies that all solutions to all problems will become clear as we work. They will not become clear if we simply talk about them. Big Up Front Design will only result in Big Wrong Design or at best Big Working But Totally Inflexible Design. When we allow solutions to emerge it is always the simplest and the most appropriate solution for the current context that rises to the surface. Emergence coupled with Empiricism will lead us to the most appropriate and the most flexible (i.e. changeable) solution.

Self-organization refers to the structure of the teams creating the product of work. Small multidisciplinary teams are empowered to make the important decisions necessary to i) create high quality product and ii) manage their own processes. The thinking here is that those doing the work know best how to do the work. These teams work in a highly interactive and generative way, emerging the product through continuous dialog, exploration and iteration. Self-organization works when there are clear goals and clear boundaries.

In addition to these principles Scrum relies on two core mechanisms: prioritization and timeboxing.

Prioritization simply means that some things are more important than others. This is obvious, yet quickly forgotten when the “we need it all now” mindset is entered. Scrum helps put the focus back on selecting the most important things to do first — and then actually doing them! Making time to prioritize, and being rigorous about it are essential to the success of Scrum.

Timeboxing is a simple mechanism for handling complexity. We can’t figure out the whole system at this time, so let’s take one small problem and in a short space of time, say one week or one month, figure out how to solve that problem. The results of that will then guide us towards a solution for the next, bigger problem and give us insight into the needs of the system as a whole.

Organizational Change

With Scrum, the management hierarchies of organizations tend to get leveled and development teams have a more immediate and direct contact with customers. The work environment becomes less command-and-control and more collaborative. Regular, open dialog is encouraged over extensive documentation, and negotiated agreement is preferred to formal and impersonal contracts of work.

The qualities of openness, honesty and courage are fostered at all levels, and individual gain becomes secondary to collective advancement. A Scrum environment is a supportive one, where people at all levels show respect and trust for one another. Decisions are made by consensus, rather than imposed from above and all knowledge is shared in a fearless and transparent way.

Scrum goes against the grain for most companies in the software industry, where a phased approach coupled with a high degree of micro-management, and an insistence on defined processes and extensive documentation have been the norm for over thirty years. Many companies rely on fear and money as the key motivators for their workers. This approach has shown short-term success but more and more companies are beginning to understand that it is not a good long term strategy. Nevertheless, the concept of changing to something as radical as Scrum strikes terror into many executive and middle-management hearts.

Scrum is still at the early-adopter stage. It will take many years for the majority of companies to recognize the benefits of creating more trustful and compassionate workplaces. Without such change many software companies will likely sink under the sheer weight of their heavy processes, and overstaffed workforces. Others – those who dare to embrace the lean, lightweight, agile approach of Scrum – stand a greater chance of surviving and prospering. For those who turn to Scrum, and fully embrace it, a reversion back to the old way of working becomes unthinkable. A paradigm shift is occurring in the workplace, and Scrum is an important part of that shift.