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.


Scrum User Stories

Posted by admin under Scrum Basics

In Scrum, work is typically expressed in the Product 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. 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 popularized by Rachel Davies and 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 often written like this: “As a [end user role], I want [the desire] so that [the rationale].

User stories are intended to help teams and Product Owners focus on the customer. Thus, it would be inappropriate to write “As a Product Owner I want ___” or “As a software architect I want ____.” Work that doesn’t directly serve a customer need is better expressed as a Sprint Task related to a User Story. These are identified during the Sprint Planning Meeting.

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 we advise one-week or two-week sprints. If a team has trouble doing a two-week sprint, we suggest trying a one-week sprint to see where the snags are.

During each sprint, a team creates a potentially shippable product increment, 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. Scrum is iterative and incremental. Because a release may require multiple sprints, each iteration of work builds on the previous (incremental), often replacing/discarding some of the previous work as more is learned (iterative).

Every sprint begins with the sprint planning meeting, in which the Product Owner and the team(s) 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 sprint execution, the team develops code and automated tests simultaneously, ideally using techniques such as Test Driven Development (TDD), pair programming, and continuous integration. Agile teams also learn to automate their system testing, performance testing, load testing, etc. so the product can be completely shippable every sprint, whether or not it has all the features it will ultimately need. This type of collaboration is more likely to occur in a team room. Good scrum teams are cross functional, meaning they have skills in development, testing, business domain (requirements) expertise, UI skills, etc. They focus on learning rather than traditional microefficiencies. Agile approaches minimize handoffs and phases.

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

After sprint execution, we conduct a sprint review meeting, in which the team demonstrates the potentially shippable product increment to the Product Owner and everyone else who’s interested.

The team also gathers in private at the end of each sprint to reflect on how things went and what they’d like to change. This meeting is called the sprint retrospective meeting.

In Large Scale Scrum, sprints are similar, but there are multiple teams pulling work from one Product Backlog, prioritized by one Product Owner (usually with advisors). Multiple backlogs and Product Owners are harmful to large scale agility. Also teams are responsible for their co-ordination with the world outside them, including other teams. Scrum does not use traditional co-ordination roles such as project manager and PMO, as these interfere with team self organization.

Watch videos of the Scrum meetings, or this overview:


Tags: ,


The Scrum Team Role

Posted by admin under Scrum Basics

There are three roles in the Scrum method of software development: the Product Owner, the ScrumMaster, and the team.

A Scrum team includes seven members, plus or minus two. Scrum teams are cross-functional, including the skills (but ideally not the job titles) of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in a team room, and collaborate more intensely than a traditional team. They avoid handoffs and phases. The ScrumMaster encourages the team to learn modern development practices such as Test Driven Development (TDD).

While the development team wants to complete the work negotiated in the Sprint Planning Meeting, the team has complete control over the amount of work it takes on. The Product Owner ensures the team takes on the highest priority work.

The team has the autonomy to determine how and when to complete its work. 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 start. 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.  

In Large Scale Scrum, teams are responsible for their co-ordination with the world outside them, including other teams. Scrum does not use traditional co-ordination roles such as project manager and PMO.

Here is what Scrum looks like from a developer’s perspective:

Tags: , ,