Scrum Methodology

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.

Tags: scrum user stories, user stories, user stories and scrum

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.

Tags: impediments with scrum, scrum impediment, scrum impediments

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

Tags: scrum sprint, scrum sprints

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.

posted by: scrum methodology

Tags: roles of a scrum team, scrum team, scrum team roles