Tips for First-time ScrumMasters

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.

Writing Contracts for Agile Development

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.

Top 7 Things to Consider When Choosing a Scrum Pilot

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.

Metrics You Can Bet On

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.

Top 7 Impediments when Implementing Scrum

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.

Top 7 Engineering Practices for Scrum Teams

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.

Top 7 Requisites for Scrum Teams

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.

Top 7 Responsibilities of a Scrum Product Owner

By Laszlo Szalvay

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

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

Top 7 Responsibilities of a ScrumMaster

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.

The Essence of Scrum

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.

Problems You Could Face While Planning Sprints Using Planning Poker

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

Problems With Using Scrum Burndown Charts to Measure Sprint Status or Progress

Scrum is touted as one of the modern new techniques that can get rid of all the problems that people have faced with earlier techniques such as Waterfall (and if one goes by correct theory, Scrum is primarily a Project Management technique, not a broad Project Development methodology. However for those people who are passionate towards Scrum, Scrum has always seemed like a solution that can work for most projects. However, people do find that their burndown charts don’t resemble the idea, with the effort needed not trending down to 0 at the end of the Sprint cycle, instead, it happens that the overall effort required remains at the end of the cycle.

This trend can be very frustrating; if you have a team with around 4 developers, and if you find that all of them have some effort pending at the end of the cycle, it could mean that all of them are just there, but not fully. Instead, there are tasks that you need to call out in the end Sprint review, and they need to be carried over to the next Sprint. Now, this would be fine and part of the normal process if the ScrumMaster is able to do a proper diagnosis of why this happened (and there are multiple reasons for why this could have happened), but when at the end, there is no proper reason, it can get very frustrating for the ScrumMaster.
It feels equally problematic when the ScrumMaster has to depend only on the burndown charts for getting the exact status; since the burndown chart is not designed for getting into the required depth (at this point the ScrumMaster would want to get into exact status of various items and compare the current status of all the tasks with the desired level of completion), and if the ScrumMaster does this often enough, they will lose interest in the Burndown chart. A lot of ScrumMasters don’t want to get into the detailed task level status, since it can be tough to then do a root level analysis of which of the tasks were delayed because of reasons that could be prevented.

What I have found (based on some of the teams that I worked with, as well as some friends who were also doing the ScrumMaster bit), we used the Burndown chart as a good indicator for showing to the team how well they are doing (including whether they were running behind and needed to check whether their velocity was good enough); for actual task tracking, we used various scheduling tools (or even used Excel as a way of tracking); it seemed a bit more effort intensive way of tracking, but worked properly and gave us a much better way of control.

The Advantages of Agile Scrum Software Development

When you start working on a project which will be developing software, you will quickly discover that the development methodology used will have a major part to play in the speed and quality of the code developed. Since Agile Scrum methodology is so widely used it is important that you understand the advantages and disadvantages of it so that you are able to determine whether it is the best fit for your project deliverables.

• Agile scrum helps the company in saving time and money.
• Scrum methodology enables project’s where the business requirements documentation is hard to quantify to be successfully developed.
• Fast moving, cutting edge developments can be quickly coded and tested using this method, as a mistake can be easily rectified.
• It is a lightly controlled method which insists on frequent updating of the progress in work through regular meetings. Thus there is clear visibility of the project development.
• Like any other agile methodology, this is also iterative in nature. It requires continuous feedback from the user.
• Due to short sprints and constant feedback, it becomes easier to cope with the changes.
• Daily meetings make it possible to measure individual productivity. This leads to the improvement in the productivity of each of the team members.
• Issues are identified well in advance through the daily meetings and hence can be resolved in speedily
• It is easier to deliver a quality product in a scheduled time.
• Agile Scrum can work with any technology/ programming language but is particularly useful for fast moving web 2.0 or new media projects.
• The overhead cost in terms of process and management is minimal thus leading to a quicker, cheaper result.

In a nutshell this means that you can get development started fast, but with the caveat that the project scope statement is "flexible" and not fully defined. Hence this can be one of the major causes of scope creep if not managed properly.