The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


Choosing a Scrum Pilot

Posted by admin under Scrum Basics

When a company is ready to migrate to Scrum, the first thing it will want to know is which of its projects would make a good Scrum pilot. If no one at the organization has past previous experience working in Scrum environments, figuring out which project to start with can leave a team feeling in the dark. After all, what attributes of a project makes it right — or wrong — for Scrum? Unfortunately, there are no cut-and-dry requirements for a Scrum project, but there are several factors to take into account when making a decision. For example, a few questions to ask would be: How does this project relate to the overall business? What kind of project is it? And does the development team have the technology to succeed?

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.

When choosing among a group of candidates, there are several factors to take into account.

  • Is there a single Product Owner dedicated to the project? Working with a single customer helps simplify communication and reduce confusion among the team.
  • 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.
  • 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.
  • 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 the team only has a foggy sense of its requirements.
  • 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.

The last thing to consider is whether the team has access to the technological resources it requires. Namely, does the team have the equipment and tools it needs to complete its sprint goals? Also, which agile programming practices are being employed? 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.



Scrum Sprint Zero

Posted by admin under Scrum Basics

So your organization has decided to implement Scrum, but you’re stuck, wondering what to do first. That’s understandable: For all of Scrum’s detailed processes, what’s the process for starting the process? Put another way, how does a team prepare for its first sprint? For many Scrum professionals, the answer is a sprint zero, a preliminary sprint exclusively dedicated to preparing for the first sprint. But which activities it includes, how long it lasts, and what it’s called are all debatable points.

In my experience, this sprint is best spent focusing on the team’s physical environment. This might include setting up computers, creating a team room, optimizing work stations, etc. Others, however, conceive of sprint zero as a chance to prepare the team for its first sprint planning meeting. For those Scrum professionals, that means sprint zero involves adding a few substantial items to the backlog and writing a piece of functioning code — no matter how small. This argument does make sense: If the first sprint kicks off with the sprint planning meeting, a Product Owner will want to have some estimated items in the backlog.

Since spending too much time on gathering requirements can lead to analysis paralysis, this sprint should be as short as possible — only as long as it takes to accomplish a few preparatory goals. Others, however, argue that sprint zero should be the same length as a regular sprint to help teams adjust to a regular work cadence. With that in mind, it’s not surprising that those who argue that sprint zero should be the same length as any other sprint also assert that it could just as easily be called sprint one. According to these Scrum professionals, the basic goals of sprint zero — design, infrastructure, process improvement, implementation, test, and validation — are the goals of every sprint.

Sprint zero is contentious among Scrum practitioners. Though they might not all agree on its name or how long it should last, sprint zero preserves the principles and processes of the sprints to follow.



Scrum with a Physical Taskboard

Posted by admin under Scrum Basics

Agile management practices, which include Scrum, were originally conceived for use in small, collocated teams. Ideally, a team’s size falls between five and 10 members, all of whom are located in the same place. With no obstructions to communication, that arrangement facilitates ongoing collaboration and optimizes the team’s productivity.

According to research, teams in such an environment prefer highly visible communication and coordination tools that reinforce collaboration. For example, physical task boards, dry erase boards, Post-It notes, index cards, and other “manual” devices are among the most effective ways to track projects for Scrum teams working in ideal conditions.

However, most complex development environments contain too many variables for small team, manual agile techniques to work effectively. As team members increase, the attributes that make manual agile so effective in small teams don’t hold up. In fact, they actually become impediments in large-scale installations. So how do team members uphold Scrum’s tenets of communication and collaboration when they’re spread across offices, buildings, or even continents? And how they replicate manual agile in this context? Facing the challenges of scaling teams usually requires an agile tooling solution. While there are several solutions available, including my own company’s product, ScrumWorks Pro, I will focus on the most common challenges to scaling manual agile.

Large Groups and Collocation
Collocation is essential for teams using manual agile. When everyone works in the same vicinity, posting requirements and updates to a physically visible location is a great solution. But once a project team grows in size beyond 10 or 20 members, it begins to lose its impact. In short, as the visibility of the posting decreases as a team member’s geographic distance increases. As the group grows larger and larger individual group members will become farther and farther from the single physically posted requirements backlog. In this case, some group members will be hindered by the lack of convenient access with requirements and prioritization decisions.

In scaled agile, individual teams could employ a taskboard, which would be a convenient information radiator for all team members. But others — such as related teams — would struggle to stay informed of the team’s progress and impediments, since the board is outside its members’ immediate proximity.

This is a problem that happens even when all group members are collocated on a single floor, within relatively close proximity to the backlog. Furthermore, this situation is amplified when team members are spread over several floors in a building or in different buildings altogether. Clearly, this problem does not go away when teams are distributed across countries, continents, and time zones.

Management of Data in Large Groups
One of the most common ways small agile teams store data, including stories and tasks, is with note cards. This marks another challenge of manual agile for large organizations. Regardless of the benefits of using note cards and sticky notes, it quickly becomes impractical when dealing with large projects.

Consider a project comprised of thousands of stories and ten times as many tasks. The task of sorting and organizing that many cards would be impossible. Suddenly, these cards would only be of value to those in possession of them, since creating and maintaining copies of thousands of cards only compounds the implausibility of the situation. Considering that cards are often revised, archiving would need to occur daily. In general, standard data organization functions are made difficult in large agile projects that use manual tools.

Visibility and Reporting Issues
Manual, paper-based tools work so well in small agile projects because they increase visibility and communication for everyone involved in the project. As mentioned before, however, using manual tools on large agile projects actually obscures data rather than make it more visible.

In such a scenario, reporting will struggle to keep up with real-time updates and may convey inaccuracies, thanks to the time-consuming process required to manually compile statistics. The backlog is a living, breathing artifact, with new cards being added, existing cards being altered, and obsolete cards being thrown away. For instance, a swing of 20 to 30 percent in total backlog effort from sprint to sprint is not unusual. For minimal summary statistics (net change), manually re-summing backlog effort is necessary each and every sprint. If more detailed change statistics are required, a manual change log of activities must be kept in tandem with the note cards.



Scrum Epics

Posted by admin under Scrum Basics

In Scrum, the teams that complete the work spend time refining the top items in the Product Backlog. To minimize work in progress, user stories shouldn’t consume more than one quarter of a Sprint. In most cases they can be made much smaller than that while still providing visible value to the customer.

What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? We call these stories “epics.” If an item require more than a quarter of a Sprint to complete, it’s probably an epic.

Estimating epics can be harmful because it creates a false sense of certainty. Instead, they should be split, as illustrated in this video.


Watch a team split epics during a Backlog Grooming Meeting.




Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

Anxiety about estimation usually means the organization is not strong in the other Agile practices such as Test Driven Development (TDD). Scrum requires that the product be kept in a potentially shippable (e.g. properly tested/integrated) state every Sprint, that the Product Owner declares which work is top priority, and that work be split into thin vertical slices, typically customer-centric user stories no bigger than a few days each. If we’re doing the other Agile stuff right, we cannot miss release dates because the product is shippable every week or two. The only downside of getting estimates wrong is that we’ll ship on time while omitting the less important features — a less stressful way to live than what waterfall or pseudo-Agile teams are experiencing today.

In waterfall, managers determine a team member’s workload capacity in terms of time. Managers ask selected developers to estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. In waterfall, tests are done after coding by specific job titles rather than written in conjunction with the code. The downsides of waterfall are well known: work is always late, there are always quality problems, some people are always waiting for other people, and there’s always a last minute crunch to meet the deadline.

Scrum teams take a radically different approach. First of all, entire Scrum teams, rather than individuals, take on the work. The whole team is responsible for each Product Backlog Item. The whole team is responsible for a tested product. There’s no “my work” vs. “your work.” So we focus on collective effort per Product Backlog Item rather than individual effort per task. Second, Scrum teams prefer to compare items to each other, or estimate them in relative units rather than absolute time units. (Ultimately this produces better forecasts.) Thirdly, Scrum teams break customer-visible requirements into the smallest possible stories, reducing risk dramatically. When there’s too much work for 7 people, we organize into feature teams to eliminate dependencies.

What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. The only estimate that’s defined by Scrum is whether a team will attempt a PBI this Sprint or not, as decided in the Sprint Planning Meeting. Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.), or simply small vs. needs-to-be-split (see #NoEstimates below).

In the Backlog Refinement Meeting, the team sits down with the Product Owner to discuss the stories toward the top of the Product Backlog. The Product Owner often wants effort estimates to help evaluate ROI, effectively prioritize items in the Product Backlog, and predict which items will be ready by a given release date. So the Product Owner wants an honest appraisal of how difficult work will be.

To gather a cross section of viewpoints despite the different personalities on a team, it is often useful for all team members to disclose their estimates simultaneously. Individuals show their cards at once, inspiring the term “planning poker.” Individuals will usually choose different cards. This should trigger discussion of the implementation approach, clarification of the requirement with the Product Owner, and splitting the requirement into smaller stories (some of which will be lower priority). Often several rounds are necessary to arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty. The refinement and clarification are more important than the estimates themselves. According to the Agile Manifesto, business people and developers must work together daily throughout the project.

#NoEstimates Controversy

In recent years, teams subscribing to the #NoEstimates philosophy have simply made all stories as small as possible. For #NoEstimates teams, the only estimate is whether a User Story is small. If it’s not small, they split it until it is small. Some of these teams still make forecasts by comparing completed stories over time to stories remaining in the release plan. The #NoEstimates approaches are gaining ground, but not universally accepted within the Agile movement.

Interfacing With Traditional Expectations

For techniques that may be more palatable to traditional managers, see Mike Cohn’s popular book Agile Estimating & Planning. Our own team used some of these approaches to make multi-month forecasts and release plans. They were still a bit off, but they were closer than anything I’d seen before. One thing that helped was doing everything possible to eliminate unnecessary unpredictability. Product development is ultimately about learning and creating, so some unpredictability is necessary. But unnecessary unpredictability can often be reduced by keeping the same team together, keeping the Sprint length the same, always building end-to-end integrated vertical slices, eliminating external dependencies, and using techniques like TDD to avoid surprise regression failures and interruptions. Bad code causes painfully unnecessary unpredictability in waterfall or Agile.

If you’re wondering how to make all this work with contracts, I’d urge you and your lawyers to read the Agile Contracts Primer.

About The Author

This article was rewritten by Michael James, an Agile coach based in Seattle (but often found in other cities). Follow MJ on Twitter or LinkedIn.


Need an example? Watch an example team conduct a Backlog Grooming Meeting, including relative estimation and example user stories. Planning poker is demonstrated at the 4 minute mark of this video:

To see how velocity is computed from story points, watch an example Sprint Review Meeting including velocity measurement.

Tags: , , ,


Scrum Acceptance Criteria

Posted by admin under Scrum Basics

In Scrum, some Product Owners would never deem a team’s work truly done without consulting the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete.

So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the item be declared partially complete? No, what’s not done is not done. (Many ScrumMasters won’t allow teams to present work that hasn’t been completed.)

Why does Scrum only accept work that is 100 percent complete? First of all, an implicit acceptance criterion of any story is that it must be completed during the sprint it was negotiated. Work is confined to the sprint, so a team tries to complete the work in that sprint as well. Second, it’s common for teams to discover the final one percent of work to be more challenging than they expected. Third, when a Product Owner declares something done that isn’t, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when something is declared done without great rigor, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.

A weak definition of done only serves to undermine a Product Owner’s ability to forecast accurately and risks building technical debt.



Scrum User Stories

Posted by admin under Scrum Basics

In Scrum, work is expressed in the backlog as user stories. A team may write its user stories in a number of ways as long as they are written from the perspective of the end user. Put another way, team members are encouraged to think of their work from the perspective of who will use it (hence “user” story). A team can express a story as a noun (i.e. “text message” on a cell phone project) or a sentence or phrase (i.e. “debug GPS tracking system”).

Many Scrum teams have adopted the user story template developed by Mike Cohn, which identifies who the end user is, what the end user wants, and why in a single sentence. This model of the user story is most often written like this: “As a [end user role], I want [the desire] so that [the rationale].

To illustrate, consider how a developer working on a calculator application for a PC might express his work. First, the developer would want to identify who will benefit from this appication: a PC user. Second, he would want to decide what the PC user will want to get out of it: a convenient, prepackaged calculator application. Third, he would want to be able to explain why it’s important for the PC user to have this application. This piece of information is the most open to interpretation, but one can safely assume that the PC user would want to use it to add, subtract, multiply, and divide. Thus the developer’s user story could read something like the following: “As a PC user, I want a calculator with basic functionality on my PC so that I can conveniently perform basic mathematic operations.”

In summary, user stories document requirements with particular attention to the end user’s point of view. Stories can be written in myriad ways, but Cohn’s model really works in Scrum because it provides so much information about the story. Because user stories are oriented to reflect the desires of the end user, they help developers remain focused on the customer.

Watch a Product Owner and Scrum Team write user stories. (Around the 7 minute mark.)


Tags: , ,


Scrum Impediments

Posted by admin under Scrum Basics

In Scrum, an impediment is anything that keeps a team from being productive. An impediment can literally be anything, from a team member who is slacking to a freezing team room. But if it’s blocking the team from performing to the best of its abilities, it’s an impediment.

To help maximize efficiency, the role of the ScrumMaster is completely dedicated to resolving impediments. The ScrumMaster works in various capacities, including helping the Product Owner prepare the backlog and ensuring that important Scrum artifacts are visible, but the ScrumMaster’s primary responsibility is to eliminate impediments and facilitate a team’s optimum performance. In this arrangement, it is the team’s responsibility to communicate what impediments are holding them back. This communication occurs each day in the daily Scrum, when team members report on what they’ve accomplished in the past 24 hours, what they plan to accomplish in the next 24 hours, and what impediments obstruct them. Scrum systematizes feedback to ensure that a ScrumMaster always knows exactly what challenges are keeping the team from success and can work to remove them.

It’s also possible for impediments to apply to an organization, particularly in regard to Scrum. Just like a broken keyboard, for instance, would prevent a team member from writing code, an organizational “culture clash” obstructs a smooth Scrum adoption. In scenarios like this, a company needs an advocate inside the company to help management recognize the benefits of Scrum. Basically, such an advocate would be acting like a ScrumMaster, removing barriers before a single Scrum team has been created. Still, even an organizational Scrum advocate does not ensure that Scrum will stick. But, like the ScrumMaster who works closely with a team to eliminate barriers, an internal Scrum advocate helps enact positive change and contributes toward a successful Scrum adoption.

The Scrum Master Checklist describes more of the Scrum Master responsibilities.

Tags: , ,


Scrum Sprint

Posted by admin under Scrum Basics

In the Scrum method of Agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. Scrum sprints used to be 30 days long, but today many teams prefer shorter sprints, such as one-week or two-week sprints.

During each sprint, a team creates a shippable product, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality. Placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. Because a release may require multiple sprints, each iteration of work builds on the previous. Scrum is described as “iterative” and “incremental.”

Every sprint begins with the sprint planning meeting, in which the Product Owner and the team discuss which stories will be moved from the Product Backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work the team will do, while the team retains the autonomy to decide how the work gets done. Once the team commits to the work, the Product Owner cannot add more work or micromanage. The Product Owner can cancel a Sprint, which shouldn’t happen often, and would usually occur due to a sudden change in business needs.

During the sprint, team members check in with each other at the daily Scrum meeting, also called the standup.

Just as every sprint begins with the sprint planning meeting, the sprint concludes with the sprint review meeting, in which the team presents its work to the Product Owner. During this meeting, the Product Owner determines if the team’s work has met its acceptance criteria.

The team also gathers at the end of each sprint to share what worked, what didn’t, and how processes could be improved. This meeting is called the sprint retrospective meeting.

Watch videos of the Scrum meetings, or this overview:


Tags: ,


The Scrum Team Role

Posted by admin under Scrum Basics

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. In my last two articles, I discussed the roles and responsibilities of the Product Owner and the ScrumMaster. Now I’ll discuss the team and its function in Scrum.

In Scrum, an ideal team would include seven members, plus or minus two. Usually, teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in the same room, called the team room.

While the development team must complete the work negotiated in the Sprint Planning Meeting, the team 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.

Similarly, the team has the autonomy to determine how and when to complete its work. As long as the team finishes its work by the deadline and under budget, it is entirely up to the team to determine how that happens. Theoretically, the team could crank out all of its work in the first half of the sprint and spend the second half lounging at the beach, as long as the work satisfies the corresponding acceptance criteria. Granted, a team typically needs the entire sprint to complete its work. Actually, it’s not unusual for teams to discover within the first few days of a sprint, as analysis becomes less fuzzy, that it has more work to do than it realized at the sprint planning meeting. Furthermore, Scrum does not award partial credit. Even if 99 percent of a project is “done,” it will be rejected if it does not meet all the established acceptance criteria. A project’s finishing touches are often the most time-consuming and labor-intensive.

Teams are responsible to inspect and adapt their process in the Sprint Retrospective Meeting.  Here is what Scrum looks like from a developer’s perspective:

posted by: scrum methodology

Tags: , ,