Scrum 101

A free online introduction to Scrum and Agile.

Scrum 101

by on

Free Scrum Training – The history of Scrum

A common question is “What does Scrum stand for?” Scrum doesn’t stand for anything; it’s a term taken from the article that inspired Scrum and derived from rugby. As Ken Schwaber, co-creater of Scrum likes to joke, Scrum is;

a cordial meeting between two opposing teams to politely discuss the ownership of a ball.

But what is the article that inspired Scrum, and where does Scrum come from? I’ll answer this and more in the video below:

Transcript

Hi, I’m Kane Mar. The starting point for Scrum is an article entitled, “The New New Product Development Game,” that was written by Takeuchi and Nonaka and was published in the January, 86 Edition of the Harvard Business Review. Let me talk briefly about why this article came to be written. Throughout the late 70s and the early 80s, there was a big push by Japanese manufacturers into the North American market.

The two most feasible markets where this occurred were the consumer electronics and the automotive markets. A good example was the Sony Walkman, which started as tape players in the early 1980s, and ended as CD players in the late 1980s. In the automotive industry, the Japanese were moving into North America.

They were doing this by producing products that people wanted of a very consistent quality. In particular, they had identified that there was a demand for small cars, that were cheap to run and maintain. By consistently focusing on the human market needs, they were able to expand their market share over a period of time.

Takeuchi and Nonaka are two widely regarded academics in Japan. They had done a survey of a whole variety of different companies including Honda, Fuji Xerox, and Canon. They had found that these companies use similar patterns to produce new high quality products. They published this work as The New New Product Development Game in the January, 86th edition of the Harvard Business Review.

This article was picked up by the creators of Scrum, Jeff Sutherland and Ken Schwaber in the early 1990s. Jeff and Ken liked the ideas presented as part of this paper and decided to apply them to their field which was software development. They iterated over these ideas for a number of years and finally formalized Scrum at a conference called OOP SLA in 1995. Many people who were new to Scrum assumed that it is an acronym, or an abbreviation. This is incorrect. The term
Scrum is derived directly from The New New Product Development Game, where they draw a direct analogy between the sport of Rugby and the creation of new products. They contrasted a sequential or relay race approach to delivering products to a Rugby approach, where the team tries to go to the distance as a unit. Always passing the ball backwards, but still moving down the field.

by on

Free Scrum Training – The Scrum Process

There are two documents that I would like to ask you to download and read. The first is “The Scrum Guide” by Ken Schwaber and Jeff Sutherland [the two co-creators of Scrum]. This is really the definitive guide to Scrum.

The second is one of my personal favourite introductions to Scrum called “Scrum in 5 minutes.” It’s a nice summary of Scrum and is beautifully produced with wonderful, easy to understand images. I often use this document when introducing Scrum to senior management and non-technical personnel.

Both documents are short, and should only take you less than 30 minutes to read. You could easily read both documents on the bus or train during your daily commute.

In the next lesson we’ll start talking about Scrum Roles and Responsibilities, but until then here’s the introductory video:

Transcript

Hello and welcome to Scrum 101, I’m Kane Mar. Scrum is an iterative and incremental software development framework for managing complex product development. Scrum starts with the role of the product owner. The product owner brings to the team a vision and a budget or some ROI or some funding. The product owner compiles a list of every that they want to see as part of the final product, and this is known as the product backlog.The product owner then orders the backlog in a single rank order, often from highest priority to lowest priority. Once the product backlog has been generated, the product owner then meets with the team as part of sprint planning meeting part one. During this meeting, the team forecasts how much work they think they can likely achieve as part of the next sprint.

They start at the top of the product backlog and will select work in priority order until there is sufficient work for the duration of the sprint. The team proceed to sprint planning meeting part two. This meeting is a design and architecture meeting, for the team, by the team, where they discuss strategies to meet their forecast.

The team dissects their work into a list of smaller, actionable tasks. This is called the sprint backlog. Once the sprint backlog is formed, the team can begin a sprint. A sprint is a time-box period of time, typically anywhere from one to four weeks, although I personally prefer a two weeks sprint.

During the sprint, the team members will have a daily scrum or daily stand up meeting, where each team member will talk about three things, what they did since the last meeting, what they’re going to do until the next meeting and any impediments that they might have. The daily scrum should be kept brief, no more than 15 minutes in total.

At the completion of this sprint, the team will meet with the part owner for this sprint review and demonstrate the result of the efforts over the last sprint. After the sprint review, the team will have a sprint retrospective. During this retrospective the team will to reflect upon their performance during the last sprint, and talk about what went well and what could be improved.

There are two other important roles within scrum. The Scrum Master, and the Scrum Team. The Scrum Master is responsible for the Scrum Process, for ensuring that the team adheres the scrum framework and is responsible for moving any impediments that the team may encounter. The Scum Team are responsible for self organizing to best meet their commitments to their product owner.

Ultimately, at the end of the sprint cycle, the scrum team is responsible to delivering the product to the product owner. Within Scrum a number of tools are used to invite feedback throughout the duration of the process the Sprint Burn-down chart illustrates the work remaining during a sprint. This is often drawn as a simple line chart I’m not a big fun of sprint burn-down graphs because they can be easily abused the better graph is the product burn-down graph which illustrates the amount of work remaining in the teams product backlog. This graph is often drawn as a bar chart with trending lines.

If you would like to understand Scrum better and lean how to use the Scrum Framework to build complex products, please continue to join me these video tutorials.

by on

Free Scrum Training – The Scrum Roles

One of the biggest advantages of adopting scrum is the roles and responsibilities. They’re very well thought out and designed to reduce conflict if interest. Within Scrum there is no hierarchy with respect to the roles. The Scrum Master is not the boss of the team, and the Scrum Master is not subordinate to the Product Owner. Rather all three roles are peers … they’re equally balanced.

In this video I introduce the three scrum roles and talk very briefly on the different responsibilities. It’s important to realize that introducing Scrum is often hard and disruptive .. and, that is also the title of one of Ken’s most important papers.

Here’s a video introducing the roles and responsibilities of Scrum:

Transcript

Hello again, I’m Kane Mar. Scrum was designed with three equally yet distinct roles. These roles are; the Scrum Master, the Team and the Product Owner. Let’s look at each of these roles. The Scrum Master. The Scrum Master is responsible for removing any impediments that the team may have, for enforcing the scrum framework, making sure that the team is fully functional and productive, facilitating close co-operation across all the different roles to shield the team from any external interference and Scum Masters are expected to be change agents, they are expected to help the organisation change that it’s better able to do Scrum.

The team is a cross-functional unit whose ideal size is seven people plus or minus two. The team has the right to do whatever is required in order to meet the team goals, they are self organizing and at the end of the sprint, the team presents the result of the efforts to the product owner, the product owner owns the vision or the desired outcome of the project.

They are responsible for the budget or the ROI and they are responsible for the product backlog. The product owner, orders the product backlog in a single-rank order from highest priority to lowest priority. Product owners are also responsible for selecting product release dates. These are the only three roles specified within the Scrum framework, the scrum master, the team and the product owner.

Scrum has been described as being hard and destructive, part of this arises because of the defined roles. With these in mind, let me ask you a question. Where do you think the role of a Project Manager fits within scrum? Until next time, thank you.

by on

Free Scrum Training – The Product Backlog

With this video I’m try to communicate two messages; firstly, the product backlog is a simple list for work, and secondly, it’s ordered in a single rank order, often from highest priority to lowest priority. Even though the Product Backlog is a simple concept it can be used to model very complex behaviors. Ken describes the Product Backlog in the Scrum Guide:
[blockquote cite=”Ken Schwaber” type=”left”]The requirements for the product that the Team(s) is developing are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, Product Backlog also exists.

The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases.[/blockquote]

You’ll notice that Scrum doesn’t dictate how to write a product backlog. For example, Scrum doesn’t dictate that the product backlog is written in the form of User Stories, although it often is. Scrum simple says that you need a Product Backlog and that it needs to be ordered in a single rank order.

Here’s an introduction to the concept and main characteristics of the Product Backlog.

Transcript

The product backlog is a list of work that is ordered in single rank order from highest priority to lowest priority. It is often assumed that work within the product backlog is all of the same granularity, but this is not the case. What we would like to see is the top 20% to be fine-grained work, the next 20% to be course-grained work, and when we 60% to be large bodies of work.

As work progresses, large bodies of work at the bottom of the product log were raised up in priority order. As those large items enter the second 20%, they’re broken down and as those items then enter the top 20%, they’re broken down further. This continual process of breaking down large items into smaller items is known as refinement, and it is recommended that teams spend 10% of their time refining the product backlog.

There are a number ways of maintaining the product backlog, and here are a few examples. My favorite way is to use index cards. Index cards are quick and easy way of ordering the product backlog from highest priority to lowest priority.

by on

Free Scrum Training – The Scrum Board or Task Board

A Scrum board (or Task board, or Story board) is a very simple Kanban board. Kanban boards have been around for a while and are originated with lean manufacturing modeled on supermarket shelf-stocking techniques.

[blockquote type=”left”]In the late 1940s, Toyota began studying supermarkets with a view to applying store and shelf-stocking techniques to the factory floor, figuring, in a supermarket, customers get what they need, at the needed time, and in the needed amount. Furthermore, the supermarket only stocks what it believes it will sell, and customers only take what they need because future supply is assured. This led Toyota to view a process as a customer of preceding processes, and the preceding processes as a kind of store. The customer process goes to this store to get needed components, and the store restocks. As in supermarkets, originally, signboards were used to guide “shoppers” to specific restocking locations.[/blockquote]

The concept of Kanban boards has been taken up by the Lean software development and Kanban communities. Although they are not formally part of Scrum, every Scrum project that I’ve been involved with in the last 10 years has used a Scrum board. They are a very effective way to measure progress. In this video, I show you how to use a scrum board.

Transcript

Hi, my name is Kane Mar, and today I would like to talk about this Scrum Board or Task Board. The Scrum Board or Task Board is a common tool that many teams will use to measure their progress throughout the duration of a sprint. I’m going to create a very simple Task Board with just four columns. I’ll start with a column for User stories, a column for Tasks not started.

A column for work in progress, and finally a column for Tasks Completed. At the start of the sprint, during sprint plan meeting part one. The team will forecast how much work they think they can likely achieve, and they will then take those user stories, and move them onto the task board like this. At the start of the sprint, during the sprint plan meeting part one, the team will forecast how much work they think they can likely achieve.

During sprint plan meeting part two, each of this stories is then broken into a number of different tasks. In our example, the first user story, may be broken down into three tasks. The second user story may be broken down into two tasks and the final user story may also be broken down into two tasks. Our team has two team members.

Alice has no work to do. So she will go to the task board and select some work from the Tasks Not Started column and move it into the Work in Progress column. Similarly, Bob may also take work from the Task Not Started column and move that to the Work in Progress column. The next day, Alice may have completed her task, so she’ll move that task into the Task Completed column.

She’ll then take a new task from the Not Started column, and place that in Work in Progress. Bob may still be working task, so that stays there in the Work in Progress column. The following day, Alice has again completed her task and she’ll move that again into the Completed column and take a new task from the Not Started column.

Similarly Bob may also have completed his work and so he’ll also move that to the Completed column, he too takes a new task from the Not Started column and moves it into the Work in Progress column. We can see a general migration of tasks from the left hand side of the board, over to the right hand side of the board.

The scrum board provides a clear and useful visual feedback, on a teams’ day to day progress. There are a variety and different styles of task boards and here, are few examples.

by on

Free Scrum Training – Sprint Burn Down graph

Sprint Burn-down graphs were created by Jeff Sutherland from ideas that he had while flying reconnisance over North Vietnam. The two may seem to be totally different but Jeff does a great job of explaining the analogy inthis YouTube video:

The are several different ways of constructing the a Sprint burn-down; the original way (as documented by Ken in “Agile Software Development with Scrum”), was to plot the total number of hours remaining on a daily basis. It’s very common to now have teams plot the total number of tasks remaining and more advanced teams will plot the total number of stories remaining. All these approaches work just fine.

When working with a team I like to draw the sprint turndown graph by hand. This is often much quicker and easier than using Excel or other tool. If you spending more than two minutes a day praying this graph you’re doing it wrong.

Here’s an overview of the Sprint Burndown graph:

Transcript

Hi, my name is Kane Mar. A common tool used in Scrum is this Sprint Burndown graph. This graph shows the total amount of remaining at the end of each day. The result is a line graph which tends to look something like this, notice the graph initially rises before trending down, this is very common. Let’s walk through this graph so that you can understand what’s happening throughout the course of the sprint, at the beginning of the sprint, the team will put forward their best estimates for total number of hours of work remaining.

The team will base their estimates on the available information over the next few days, the team will better understand the reality of their commitments and are likely to adjust their estimates accordingly. Typically time estimates increase, this could be due to poor code quality or documentation. The teams estimates tend to increase over the next two or three days and after two or three days today, the team will have a much better understanding of the work required to achieve their commitments.

And so the team starts to burn down the total number of hours estimated, until they’ve completed the sprint. Occasionally, you may see a burndown graph that looks like this, a nice predictable straight line. There’s a common name for this graph. It’s known as a Big Fat Lie, and the reason for this, is because, this graph shows no understanding of the realities of the situation, and demonstrates little comprehension of the code.

Beware of straight line graphs. I’m not a fan of sprint burndown graphs, because they can be easy manipulated and misinterpreted. I find product burndown graphs to be much more useful. And will discuss product burndown graphs in our next two episodes.

by on

Free Scrum Training – The Product Burn Down graph

Similar to the Sprint burn-down graph, the Product burn-down graph is a way to track progress. In this case we’re tracking progress against the entire product that we’re building. The example that I use in this video was very popular several years ago. Since then, Mike Cohn’s Alternative Product Burndown graph has become more popular, and that’s the topic of the next video.

Until then, here’s the traditional way of building and using a Product burn-down graph.

Transcript

Hi there I’m Kane Mar. let’s talk about the Product Burndown Graph, the product Product Burndown Graph shows the total amount of work remaining at the start of each sprint. This graph can provide useful feedback illustrating both the residual reduction of the product backlog and how the team is performing as a self organizing unit.

To plot this graph, the team would calculate the total amount of work remaining in the product backlog and plot this as a bar graph at the start of each sprint, for example here our team has completed four sprints, during each sprint an amount of work was completed reducing the height of the bar graph.

Our example teams for the Product Burndown Graph may look like this. By referring to the difference in bar heights between sprints one and sprints two, we can see an amount of work was completed from the Product Backlog. Similarly between sprints two and sprints three, further work was completed and between sprints three and four yet more work was completed.

We can now project a trend line through the top of graph as extrapolate a date when we think we might finish the product. But what happens if new work is introduced into the Product backlog by the product owner? What happens if work is re-estimated by the team? How do we account for this changes? although this graph works well, it is limited in presenting the full scope of changing conditions faced by most Scrum teams.

A better solution to this problem Scrum is Mike Cohn’s Alternative Product Burndown graph. This is the subject of our next video. Here are some common examples of Product Burndown Graphs.

by on

Free Scrum Training – Alternative Release graph

Mike Cohn’s Alternative Release Burndown graph is my preferred burndown graph. It’s simple, clear and offers a wealth of information. This lesson is all about the Alternative Release Burndown. After watching the lesson you may also want to read Mike’s summary, which you can find here: http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown

Creating this graph is a little bit more complicated than a Sprint burn-down graph. There needs to be a record of work created, work completed and calculation of the trend lines. The simplest solution is a spreadsheet, and I’ve created a Google spreadsheet for you to explore. I also wrote a full article explaining this graph in detail.

But before you dive into the details, let me explain how the graph is structured and how it can be used:

Transcript

Hi, I’m Kane Mar. Let’s talk about the alternative product burndown graph. Of all the Scrum tools, this is my favorite, as it tracks the behavior of the team and the behavior of the product owner. In the beginning of this print, the team calculates the total amount of work remaining in the product backlog, and this is plotted as a bar graph.

Thereafter any work completed by the team is taken from the top of the graph. You can see the amount of work completed by the team by the differences in heights in the bars. In our example, between sprints one and sprints two, work was completed by the team between sprints two and sprints three again work was completed by the team.

And between sprints three and four, more work was completed by the team but what happens if work is introduced into the product backlog? What do we do about new stories added by the product owner? How is this handled? Work added into the product backlog is added to the bottom of the bar graph. For example no new work was added to the product back log between sprints one and sprints three, however between sprints three and four there was work added to our product backlog and similarly between sprints four and sprints five.

If a trend line is drawn to the tops of the graph it shows the team is making steady progress in completing the work in the product backlog, it shows the rate in which work is being completed by the team, if the trend line is projected through the bottom of the graph, it shows the rate at which the work is being added to the product backlog by the product owner.

These two trend lines can then be used to extrapolate for completion date of the product. If the product backlog remains static, the earliest completion date is where the current baseline meats the blue trend line. If however the baseline of product backlog continues to change, then the most likely completion date will be at the intersection between the blue trend line and the red trend line.

The alternative burndown graph can be used to provide a time frame for when the product is likely to be completed, between the earliest completion date and the most likely completion date. It is a useful tool because it shows how the team has been progressing but also illustrates how the product owner’s behavior can influence the final completion date of the product.

In our next episode we will look at Extreme Programming and Scrum, until then thank you for your time.

by on

Free Scrum Training – Sprints

Sprints are invariant durations of time. The longest sprint duration that Scrum allows is 4 weeks. To be honest, I feel that a 4 week sprint is far too long before providing feedback to the Product Owner. The shortest Sprint duration is 1 week. Most teams have a Sprint duration that’s either 2 weeks or 3 weeks long. I personally prefer a 2 week sprint because I feel it’s a nice balance between providing regular feedback to the Product Owner, and is still long enough for the team to actually deliver some increment of potentially shippable product. Everything in Scrum happens within the duration of a Sprint, and we the repeat the Scrum framework Sprint-over-sprint-over-sprint.

Sprint durations are decided at the start of a project, and once decide the sprint duration remains unchanged. For example, we don’t do a 3 week sprint followed by a 1 week sprint. If we’re working with a 3 week sprint, then its always 3 weeks long.

In a similar fashion, we never extend the sprint by a few days, nor do we shorten the sprint by a few days. So, here are two question for you to consider. If the team finishes all their work two days before the end of a sprint, what should they do? If the team requires just two more days to complete their work, what should they do?

Transcript

Hi, my name is Kane Mar and today I’d like to talk about the flow of a sprint. For this example, I’d like to consider a two weeks sprint cycle. Personally I like to start and end sprints mid-week on either a Tuesday or a Wednesday or a Thursday. This is because public holidays often fall on either a Monday or Friday.

If a sprint cycle falls on a public holiday, what do you do? Do you shorten the Sprint? Or, do you lengthen the sprint?

By having sprints with mid-week schedule, we avoid this unnecessary complication. Personally I like to start sprints on a Wednesday afternoon. Wednesday afternoon at 1:00 pm. On Wednesday afternoon at 1 pm I would meet with the team and the product owner and we would collectively sit down and do sprint planning meeting part one.

This takes two hours for a two weeks sprint. Once complete, the team will continue with sprint planning meeting part two, this will also take two hours and we will finish at 5:00 PM on a Wednesday afternoon. For the next two weeks the team will work towards their agreed goals, and every single day they will have a daily scrum.

Two weeks later on Wednesday at 8 AM, the team returns to undertake a sprint review with the product owner. In the sprint review the team presents the results to their efforts to the product owner. Once the sprint review is completed the team will then do a retrospective. This timeline typically allows the team to finish up at 12 noon, an appropriate time to break for lunch.

By organizing the schedule in this manner sprint cycles can be lined up back-to-back, separated by one hour for lunch.

by on

Free Scrum Training – Scrum and XP

There is often confusion about Scrum and XP. The are both Agile frameworks because both were represented as part of the creation of the Agile Manifesto and yet they have their differences. Is it possible to use elements of both? And, if we wanted to do that how should we go about it?

I tried to answer these questions as part of the 2010 Shanghai Scrum gathering and I’ve finally found time to created a version of that presentation suitable for the web. This is an abbreviated version of the full talk which lasted over 40 minutes but I tried hard to hit the key points. It’s just over 3 minutes long.

Finally here’s a copy of the original paper that talks about combining scrum and xp that I wrote with Ken back in 2002. It’s dated now, although it may give you some different ideas: http://www.informit.com/articles/article.aspx?p=26057

Transcript

Halo again, I’m Kane Mar. Often in the context of Scrum you may hear about XP or Extreme Programming. Today I’d like to talk about Scrum and Extreme Programming, and how they relate to each other. The Scrum framework defines roles and events without defining explicit technical guidance on how to build products in a move to include technical processes, Kant Beck and Ward Cunningham modified the scrum framework by adding explicit technical processes such as Continuous Integration, Test Driven Development and Pair Programming.

This modified framework began the basis of Extreme Programming. Ken Beck and Ward Cunningham were not the only one to take this approach, Ken Schwaber, one of the co-creators of Scrum created his own personal approach which he called XP@Scrum. and Mike Beedle, Ken’s co-author on Agile Software Development with Scrum created a separate approach called XBreed. Simplicity has always been one of Scrum’s strength and it was decided that technical processes should remain outside of the Scrum framework.

This effectively divided Scrum and Extreme Programming into two separate camps. How do Scrum and XP differ? Both frameworks face a different emphasis on process. Allow me to demonstrate. Commonly, Scrum is described by the Scrum Roles, events or meetings and the artifacts. The diagram you see here is one of the more common diagrams that summarizes the Scrum process and was taken from Ken Travis’ first book.

Extreme Programming focuses on the technical aspects of product development. The technical practices can be grouped under common attributes including Feedback, Continuous process, shared understanding and programmer welfare. This diagram was created by Ron Jeffrey and illustrates the frequency of a lot of practices and their relationship to each other for example technical practices towards the center indicated by the blue circle are undertaken multiple times per day. Technical practices indicates indicated by the green circle may only be undertaken once a day.

Note the overlap of the two diagrams. Here the common processes between Scrum and XP become self evident, Scrum focuses always on big picture things, cultural and systemic change while extreme programming focuses inwards on the engineering themes. One common assumption is that Scrum is considered to be a project management approach, whereas XP is considered to be a combination of both project management and technical processes.

This is an over simplification of the true nature of the the respective frameworks. Despite the differences, there is a natural attraction between the two. Most high performing teams naturally use both Scrum and extreme programming together an example of this is extreme programming practice of continuous integration.

Without continuous integration, it quickly becomes impossible to produce an increment of potentially shippable product at the end of every single sprint. Scrum doesn’t explicitly mandate how a team should build the product but it will drive the team towards adopting the extreme programming technical practices after just a few sprints. Combining Scrum and extreme programming is a powerful way to take teams to the next level.