The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.


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 assign effort estimates to every user story. Of course, that assumes that a team can reach a consensus for an appropriate estimate. 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.” While a team should be able to tackle a typical story in four to sixteen hours, an epic is a story that would require twelve or many more to complete. Most Scrum experts suggest that any task requiring twelve or more hours should be decomposed into several smaller tasks. These stories will not only be smaller in scope, but also more narrowly defined. Basically, breaking down epics helps the development team translate its work into chunks that can be accomplished in a single day.

Is there any danger to estimating an epic? Quite simply, the answer is yes. Estimating epics can be harmful because it creates a false sense of certainty for the Product Owner, who begins to believe that the belief that the requirements, tasks, and effort of the epic are known. When a team estimates an epic, that estimation is just that — an estimation — but it seldom remains a best guess. It is often used for forecasting, which, in turn, becomes the basis of a budget. When that happens, that estimate is now an inflexible projection that binds the team to complete an unknown amount of work while respecting an established budget. This strategy is akin to a trip to the supermarket with a fixed amount of money to spend, but no idea what needs to be purchased. It’s safe to assume that anyone in that situation would have plenty of questions. What am I making? What ingredients are in it? If I can’t afford all of the ingredients, which ones are the most important? Basically, this shopper is left in a tough position: He knows he has a meal to prepare and ingredients to buy, but, apart from that, he’s in the dark. The same could be said of the Product Owner who commits to an estimated epic.


Watch a team split epics during a Backlog Grooming Meeting.




Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

In waterfall, managers determine a team member’s workload capacity in terms of time. That is, managers estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. This is problematic because it does not distinguish between a story that is very hard to complete and one that is undemanding; it only considers how long the work will take. To put it another way, coding a feature and organizing the heaps of documentation on your desk are activities that likely take the same amount of time, but there’s no question that the former would require much more sustained concentration and effort. Because of that fact, they should be recognized as incredibly different tasks, requiring different levels of effort.

Scrum takes a considerably different approach to determining a team member’s capacity. First of all, Scrum assigns work to an entire team, not an individual. Philosophically, this places an emphasis on collective effort. Second, Scrum teams prefer not to quantify work in terms of time because this would undermine the self-organization central to the success of Scrum. This is a major break from waterfall: Instead of a manager estimating time on behalf of other individuals and assigning tasks based on conjecture, team members in Scrum use effort and degree of difficulty to estimate their own work.

What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. However, it does ask that teams not estimate in terms of time, but, instead, use a more abstracted metric to quantify effort. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), and even dog breeds, in which a Chihuahua would represent the smallest stories and a Great Dane the largest. The important thing is that the team shares an understanding of the scale it is uses, so that every member of the team is comfortable with the scale’s values.

In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals “show their hands” at once, this process is not unlike a game of poker. Unsurprisingly, teams often call estimation “planning poker.” Some teams have even developed their own decks of playing cards expressly for this process.

Still, even when teams possess a shared understanding of their scale, they can’t help but estimate differently. To arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty, it often requires numerous rounds of estimation. Veteran teams who are familiar with the process, however, should reach a consensus after just a few rounds of planning poker.

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, a Product Owner would never deem a team’s work “done/done/done” until he or she had consulted the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete. Acceptance criteria are incredibly important in Scrum because they spell out what a Product Owner expects and what a team needs to accomplish. There are no hairs to split and no points to argue. If it’s in the acceptance criteria, then it needs to be in the release.

So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the team be awarded a corresponding percentage of the story points? Well, no. Scrum frowns on partial credit for work that is only partially completed. All of the criteria must be fulfilled or else the work is incomplete. (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 assigned. Work is confined to the sprint, so a team must 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. It might sound like a Yogi Berra-ism, but if it’s not done, it’s not done. Third, when a Product Owner awards unearned credit, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when a team is awarded credit for a story that it will have to finish in the next sprint, it means the team’s workload is even greater than the sprint backlog suggests. When this happens, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.

Clearly, it is in the interest of the team to only award credit when it is completely earned. Partial credit 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. In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints. But how long each sprint lasts is something for the team to decide, who must weigh the advantages or disadvantages of a longer or shorter sprint for their specific development environment. The important thing is that a sprint is a consistent duration.

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. However, 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 requires many sprints for satisfactory completion, each iteration of work builds on the previous. This is why 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, alter course mid-sprint, or micromanage.

During the sprint, teams check in at the daily Scrum meeting, also called the daily standup. This time-boxed meeting gives teams a chance to update project status, discuss solutions to challenges, and broadcast progress to the Product Owner (who may only observe or answer the team’s questions).

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. If a single criterion is not met, the work is rejected as incomplete. If it satisfies the established criteria, then the team is awarded the full number of points.

Because certain sprints are hugely successful and others less than ideal, a 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.

posted by: scrum methodology

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: , ,