What is Scrum?

Posted by Kevin Kelly on 10/1/09 | DotNet

The Senior C# developer position you’re applying for at HealthyBank is being advertised for a team using Scrum as part of their agile software development process. You’ve been paying attention over the past five years and know that agile software development is a big umbrella term for development practices like test-driven development (TDD), unit testing frameworks, continuous integration, and pair programming (yum). Scrum fits under the agile umbrella as a framework for managing the queue of work facing a development team.

What is Scrum?

Scrum is a project management technique, not specific to but most often applied, to software development projects. Simplified, project management techniques are distilled into tools for managing people, resources, and time.

People (or roles)

HealthyBank is screening you for a position on a Scrum Team. Scrum Teams are cross-functional; they consist of everyone necessary to make the software. On idealized Scrum Teams anyone can do anything the team needs to do. You should test this ideal as you investigate the HealthyBank position. Teams with more specialized individuals (dev v. test, UI v. server) are less flexible, er, agile, and ultimately less productive. Size matters too. Ideally the team is seven people, plus or minus two. They are co-located, working together in the same location, on the same schedule. The Scrum Team owns their plan, schedule, and quality. It is an organic, self-organizing, business-value producing unit.

The Scrum Master is the member of the Scrum Team who organizes the team’s product development activities. The Scrum Master is a “servant leader” who spends time every day making sure each individual on the team has the information and resources needed to make progress, and that no one is blocked by others on or off the team. They run the daily meeting and handle coordination with others outside the team. The Scrum Master may be a developer on the team, but the Scrum Master is never the Product Owner.

The Product Owner is outside the Scrum Team and controls the list of prioritized work for the team. The Product Owner may stop work and repurpose the whole team at any time. For commercial development, the Product Owner may be known as the product manager. For in-house development efforts, the Product Owner could be the business department manager.

Time (or schedule)

Instead of trying to anticipate all project tasks ahead of time and scheduling them using traditional project management methods, Scrum Teams work in fixed length iterations, or Sprints, of two, three or four weeks. The team chooses iteration length. Using the Product Owner’s prioritized list as a guide, the team estimates the highest priority requirements and schedules them into a Sprint. Working in Sprints allows the team to collect data on their ability to estimate and execute over consistent periods of time. Each Sprint must produce demonstrable results in the form of potentially shippable functionality. Working in Sprints may be the biggest difference you’ll encounter from traditional methods.

Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. During the meeting, each Team member explains:

1. What he or she has accomplished since the last meeting,

2. What they are going to do before the next meeting, and

3. What obstacles are in their way.

Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve everyone’s level of project knowledge.

The Scrum Master ensures the Team has the meeting. The Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Team to keep the Daily Scrum short by enforcing the rules and making sure that people speak briefly. The Scrum Master also enforces the rule that people who are not on the Scrum Team are not allowed to talk at the Daily Scrum or in any way interfere with it.

There are three points in Scrum where the Scrum Team or Product Owner can change the plan or the change the process of development. Sprint Planning and Sprint Review meetings are used to inspect progress towards the product goal, and to make adaptations that optimize the value of the next Sprint. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next workday. Finally, after every Sprint, a Sprint Retrospective meeting is used to adapt the process and interactions of the previous Sprint, and to make adaptations that make the next Sprint more productive.

Features (or work)

Scrum Teams use two tools to help them organize and decide what they will do. The first is a Product Backlog, which is simply a list of priorities for the project expressed as user stories. The amount of information in these user stories can fit on the back of index card. They are not very detailed. The Product Owner maintains the Product Backlog and decides the priorities of the list.

The second tool is the Sprint Backlog. This is the list of work the team has taken off the Product Backlog to accomplish in a Sprint. During the Sprint Planning meeting the Scrum Team estimates the level of effort for each item. Estimates become more accurate as teams accomplish more Sprints together. One of the important side effects of working in iterations is the team’s ability to collect their own performance data and use it immediately to adjust estimates for the next Sprint. The Scrum Team owns the Sprint Backlog, they build it in collaboration with the Product Owner, but once the Sprint is underway the Team controls all the decisions about how the work is done.

The primary tool the Scrum Team uses to report on progress of the Sprint is the Sprint Burndown Graph. It’s updated daily and discussed at the Daily Scrum meeting. The Y axis represents work remaing and the X axis is time. The slope of the graph is negative, or should be, as the team completes items on the Sprint Backlog. The Sprint Burndown Graph is critical for answering the question “are we going to get everything done on time?” If it becomes obvious to the team that they cannot, they send the Scrum Master (Ha!) to renegotiate the remaining Sprint Backlog items with the Product Owner.

Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable, because a Product Owner may choose to immediately implement the functionality. To do so, the increment must be a complete slice of the product. It must be “done.” A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation, and testing for the increment and all Product Backlog items in the Sprint. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. “Done” includes any internationalization. Some Teams aren’t yet able to include everything required for implementation in their definition of done. This must be clear to the Product Owner. This remaining work will have to be completed before the product can be implemented and used.

Hopefully this piece gives you a quick refresher and talking points to answer first-level questions for your interviewer. If you’d like a bit more information about Scrum, a great little summary of Scrum can be found here. Finally, use the discussion of Scrum to learn and explore how HealthyBank does development. Even if you don’t get the job, you’ll have a few more observations in your personal database afterwards. Best of luck!

About Kevin Kelly


Kevin Kelly , program and product manager on Microsoft engineering teams from 1995 to 2009, contributed to the Visual Studio product line. Kevin currently serves as consultant to SetFocus on curriculum development for their .NET Master’s Program and on the application of VSTS and agile software development practices across the SetFocus product portfolio. Check Kevin out on LinkedIn and at his blog!

Kevin Kelly on LinkedIn
Kevin Kelly's blog



.NET Training and "How to" prepare for your next .NET Developer job

If you are considering a position as .NET developer and need the background and experience to be able to answer the question “What is Scrum?”, consider SetFocus to train for the next step in your career and to network with companies seeking .NET developer talent.  SetFocus offers a number of ways to learn .NET and become a .NET Developer. 




















 


0 Comments

COMMENTS

Name:
URL:
Comment:

Comments are disabled for this article.