The course covers topics such as the Scrum meetings, artefacts, roles and responsibilities. All packaged up with a bunch of immersive exercises to strengthen the learning. It’s the first course world wide to meet the newly release Scrum Alliance Scrum Foundations Learning Objectives.

We’ve see increased interest in the course over the last 2 years, and it’s become one of our most popular private courses. We’ve decided to open this course to the public for the first time. You can register groups for this course, here: https://www.eventbrite.com/e/scrum-for-teams-tickets-38645482679

]]>When developing or refining a product backlog I have regularly encountered the problem of “implementation details” in product backlog items. This problem usually looks like a member of the development team crankily addressing the Product Owner about content of a user story. I think this highlights a misunderstanding in how to work with a product backlog and work in a Scrum Team, I don’t think the problem is the one most people think it is.

For most Development team members “implementation details” are about having the Product Owner telling them how to do their job. This is a legitimate concern because we want everyone in a Scrum team to be able to work with a degree of autonomy even though their work is interdependent.

From the Product Owner’s perspective the detail they want in their product backlog items is used to describe the product increment the item creates. This means they will want to make the item as descriptive as possible of their idea. Once they get into this detail the Product Owner may start to describe what can be construed as details the Development team would work out.

The problem is not that there are “implementation details” in the product backlog items. The real problem is how this information gets there.

The crux of the problem is a lack of *collaboration*. A product backlog item needs to be an enabling specification such that the Development team can get on with building the product increment with little need to go outside the team. To create a product backlog item to this standard requires more than a Product Owner burning the midnight oil the day before Sprint Planning. To achieve this requires ongoing collaboration across the Scrum Team.

When a team collaborates on the product backlog they start to record information they need to remember during the Sprint. This information may include “implementation details” and in this situation the information is collaborative identified and recorded. I don’t know where I picked the phrase up but I often describe this as “write to remember” and I contrast this with “write to communicate”.

To get this collaboration happening the Scrum team needs to spend their time refining the product backlog. The team has up to 10% of the Sprint to work on this. For a 10 day sprint this is one day! Imagine how much refinement the team can get done in a day. “Are you recommending we spend a day per Sprint refining? That’s nuts”. I am saying you have up to a day (in a 10 day sprint) to get the product backlog in a useful state. As much as Scrum is about building product increments it’s also about building the product correctly and efficiently and that’s what this time gives you so use it well.

]]>I created this with Excel while working with an insurance company based in Mayfield, Ohio. In this article I’ll show you how to create something similar using Google docs.

This graph (above) shows the total amount of work in the product backlog (top line of the graph), the amount of work completed (yellow) and the amount of work remaining (red and blue). The amount of work remaining is divided into estimated work (red) and un-estimated work (blue) which we guessed at using a very course scale. At the start you can see the total amount of work on the backlog increase until the fourth Sprint as indicated by the rising top-line of the graph.

After the fourth Sprint the team decided that they needed to start breaking down the un-estimated work into small User Stories and so you can see an increase in the red area of the graph and a decline in the blue. We continued to complete work, so the yellow area continued to grow.

By Sprint 12 we had completely broken down all the large bodies of work and had a well refined backlog.

The Google graph that I’ve created is a little bit simpler than the graph above. It shows the total amount of work in the product, the total amount of work added to the product backlog, and the total amount of work completed. You can get the Google Spreadsheet document to create this graph here.

This is what it looks like:

The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. To start using this graph,

- Make a copy of the Google Spreadsheet
- Enter the total of the teams estimates in the product backlog into the first column of Series A.
- There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
- The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.

You can get the Google Spreadsheet document to create this graph here.

]]>Here’s what the Alternative Burndown Graph looks like.

I’m frequently asked if I have a version of the graph that I can share, so I created a Google spreadsheet to generate a simple and useful version of the graph. You can get a copy of my Google Spreadsheet here.

The Alternative Burndown Graph is started by adding up the total amount of work remaining in the Product Backlog [1][2], and plotting this initial value. There after, any work completed by the team is taken from the top of the graph. By drawing a trend line through the tops of the graph we can show how the team is making progress Sprint over Sprint.

But what about work being added to the Product Backlog? With this style of graph, any work added to the Product Backlog is added to the bottom of the graph. And, by drawing a trend line through the bottoms of the graph we can show how the baseline of the Product Backlog has been changing Sprint over Sprint.

Finally, we can then use all this information to help calculate when we think the team will have completed the work in the Product Backlog. The intersection of the two trend lines is where the Product Backlog will give us the most likely time of completion of this Backlog.

It’s a very easy graph to generate with any simple spreadsheet application, but I’m frequently asked if I have a sample version of the graph that I can share. So, here’s a version as a Google spreadsheet.

The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. The graph is generated using the data in the rows titled Series A and Series B.

To start using this graph,

- Make a copy of the Google Spreadsheet
- Enter the total of the teams estimates in the product backlog into the first column of Series A.
- There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
- The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.

So, there you have it. A nice simple Alternative Burndown. Let me know if you find this useful.

[1] Teams will seldom calculate the total amount of work for the entire Product Backlog … because this might be a large amount of work especially for very large Product Backlogs. It is more likely that the Product Owner and team will select some subset of the Product Backlog (say the top 20%, or perhaps sufficient work for the next release) and use then generate this graph for that subset.

[2] That fact that we need to ‘add up the total amount for work remaining the the backlog’ is often interpreted as an implication that we need a numerical scale. This is not so; we can easily use an abstract scale although it’s something most people are uncomfortable with. To make it easy to generate this graph many teams will adopt a numerical sequence, but its important to remember that it doesn’t matter what scale you use, provided that you’re consistent.