Scrum evolution over time: Part 4 – Artifacts

In Part 1 of Scrum evolution over time we looked at the high level overview of Scrum and how it has changed over the years. In part 2 we looked at the roles and part 3 we looked at the ceremonies and how they have adapted, or not, over the years. It is now time to have a look at the key artifacts.

There are three artifacts in Scrum: Product Backlog, Sprint Backlog and the Burn Down Chart.

Product Backlog

The original June 2003 site did not differentiate between the Product and Sprint Backlog:

A prioritized list of all work to be completed prior to releasing a product :

Only one person maintains and prioritizes the backlog list.
Any interested party can request that backlog be put on the list.

Between sprints, all involved parties and the engineering team meet to determine which work can be completed in the next sprint, and what the executable will be.

In the 2007 pdf we have the Product Backlog defined as:

The requirements for the product being developed by the project(s) are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. The Product Backlog is never complete, and the Product Backlog in the project plan 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 emerge. The Product Backlog is dynamic, in that management constantly changes it to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, the Product Backlog also exists. An example of a Product Backlog maintained on the Scrum Product Management tool, based in a spreadsheet.

In both March 2007 and March 2009 the Product Backlog definition was:

At the beginning of the project, the product owner prepares a list of customer requirements prioritized by business value. This list is the Product Backlog, a single list of features prioritized by value delivered to the customer. The Scrum Team contributes to the product backlog by estimating the cost of developing features.

The Product Backlog should include all features visible to the customer, as well as the technical requirements needed to build the product. The highest priority items in the Product Backlog need to be broken down into small enough chunks to be estimable and testable. About ten developer-days of work is a good size for a Product Backlog item that can be ready for implementation in the next iteration. Features that will be implemented further out in time can be less detailed.

In September 2010:

The Product Backlog is a prioritized list of everything that might be needed in the product.

Within scrum.org the definition is now:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of 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 Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate.

The Product Backlog is often ordered by value, risk, priority, and necessity. Top-ordered Product Backlog items drive immediate development activities. The higher the order, the more a Product Backlog item has been considered, and the more consensus exists regarding it and its value.

Higher ordered Product Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are fine-grained, having been decomposed so that any one item can be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “ready” or “actionable” for selection in a Sprint Planning Meeting.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items is then employed.

Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

The ScrumAlliance definition of the moment is:

A prioritized list of desired project outcomes/features.

A product backlog is dynamic—Items may be deleted or added at any time during the project. It is prioritized—Items with the highest priority are completed first. It is progressively refined—Lower priority items are intentionally coarse-grained.

Product Backlog results and opinion

My biggest problem with Scrum (other than it’s odd names for things) is that it creates this belief that this backlog of requirements just pops into magical existence with no work. This is not an activity that a Product Owner can do in a few hours. Nor is it something they should do alone. The whole team should be part of this activity to create the backlog in the first place. This is an opportunity for the team to be given context as to why this project came into existence in the first part, the opportunity to say we need to have a team or 6 or a team of 3 to get through the work in time against expectations. There is no recognition in Scrum of marketplace realities – projects are almost always constrained by either scope, time or cost. Vendors do need to still give some form of estimate of the end to end work – yes with knowledge that change will without a doubt occur, but the financial reality of this world is that software development work is capitalised by accountants and consequently needs to have funding set aside for it in advance. To do this the whole team needs to have a somewhat good understanding about the features and about the market pressures. I used to call this activity “Iteration Business Planning” and it would precede the start of iterations. An outcome of it would be a business case for the work to be done.
Now before you start replying that this smells like waterfall I would say that it is a compromise. In waterfall such an activity would have taken months – what I am suggesting is that for a six month project this takes one week. It’s not big design upfront, it is the right amount of design and elaboration to ensure that you are building the right thing and that the right thing can be built to commercial expectations.
Thankfully over time the creator of the requirements was changed to not just be the customer or “Product owner” but that also the team could identify requirements. This hints at there being IT only features. The thing to be wary about IT only features is that they provide no value to the Product Owner, hence why are you doing them? If you can express in what way they provide value to the Product Owner (which you should) then they are really Product Owner features. Work such as “setup the database” is not a feature – you are doing that to realise some value in a real Product Owner feature.
All instances above take the line that prioritisation is only done by value. I would argue along with other Agile proponents (eg Alistair Cockburn and Jeff De Luca) that prioritisation should be done with respect to value and risk. This doesn’t mean that you do all the high risk features first. You do the high risk, high value features first. You do the high risk, low value features near the end (or never). It would be nice if Scrum was updated to provide further guidance on this.
The question of how often to Product Backlog groom (prioritise, estimate and discover) is an interesting one. Scrum.org says to do it as needed with this activity taking up to 10% of the Development team’s time in interruptions. I agree with the ‘do it as often as needed’ philosophy but be careful about how you implement this. It is important not to make the developers context switch too much and constant interruptions by the Product Owner of “hey, can you estimate this new feature for me?” is not the intent of this activity. Ensure that as a team you have worked out a strategy to minimize context switching but still enabling this to be an activity that doesn’t get skipped.
The fact that the Product Backlog will evolve over time is an important one. What I do get concerned about here is the commercial reality behind it. A certain amount of tolerance can probably be handled but how much are Product Backlogs changing out there? I really would love to see all of the Release Burn Charts across the industry to see where the scope was when the project started versus where it ended up being. Should we as a community not be gathering this information and asking questions about why it is shifting so much and whether there is a better way to predict such dramatic shifts in the future?
In the March 2007 data capture, the ideal size of a feature was defined as 10 days. Scrum.org has now clarified that it just needs to be doable inside of an iteration. Both of these definitions scare me a little. Probably because I think of a “feature” as the big thing that a customer wants eg “Manage my accounts”. Most people outside of Scrum these days are using a Feature -> Epic -> Story -> Task breakdown (or something similar). The Story (or User Story) should be no bigger than a Sprint. Ideally the Story should be around 2-3 days in length – why? So that demonstrable results are being showed very frequently, ie the feedback loop is tight. A feature could be made up of potentially dozens of Stories that cross multiple Sprints. A Feature Progress Chart (or Parking Lot diagram in FDD) provides a visual cue as to how well this feature’s delivery is progressing.
I do appreciate the approach that Features further (ie lower in priority) out need less elaboration or breaking down. In this respect all Features need a high level estimate on them but only as they get closer to being put in a sprint does the breakdown need to occur. The reason for this is that it is ultimately waste to break down work that is only possibly going to be done. Elaborate just enough, just in time.

Sprint Backlog

In the 2007 pdf we have the Sprint Backlog defined as:

The Sprint Backlog defines the work, or tasks, that a Team defines for turning the Product Backlog it selected for that Sprint into an increment of potentially shippable product functionality. The Team compiles an initial list of these tasks in the second part of the Sprint Planning meeting. Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish. Tasks that are of longer estimated time are used as placeholders for tasks that haven’t been finely defined. Only the team can change the Sprint Backlog. The Sprint Backlog is a highly visible, real time picture of the work that the team plans to accomplish during the Sprint. The rows represent Sprint Backlog tasks. The columns represent the days in the month of the Sprint. Once a task is defined, the estimated number of hours remaining to complete the task is place in the intersection of the task and the Sprint day by the person working on the task.

In both March 2007 and March 2009 the Sprint Backlog definition was:

The Sprint Backlog is an artifact of the Sprint Planning Meeting. When the Scrum Team has selected and committed to deliver a set of top priority features from the Product Backlog, the Product Backlog’s features are broken down into a Sprint Backlog: a list of the specific development tasks required to implement a feature. These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work. When the Sprint Backlog is complete, the total work estimated is compared with original estimates from the Product Backlog. If there is a significant difference, the team negotiates with the Product Owner to get the right amount of work to take into the Sprint with a high probability of success.

In September 2010:

The Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product.

Within scrum.org the definition is now:

The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality.

The Sprint Backlog defines the work the Development Team will perform to turn Product Backlog items into a “Done” Increment. The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog items can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum. The Development Team tracks these sums daily and projects the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

The ScrumAlliance definition of the moment is:

Sprint backlog: set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks.

A sprint backlog is a negotiated set of items from the product backlog that a team commits to complete during the timebox of a sprint. Items in the sprint backlog are broken into detailed tasks for the team members to complete. The team works collaboratively to complete the items in the sprint backlog, meeting each day (during a daily scrum) to share struggles and progress and update the sprint backlog and burndown chart accordingly.

Sprint Backlog results and opinion

This wider community belief of breaking work down into Feature -> Epic -> Story -> Task is muddying the ‘task’ definition. For me a task is something more fine-grained then Scrum’s definition. It doesn’t add value and it is there more for the developer to be able to track the things that they have to do – eg “Create a new business object and update the Customer business object”. But to take Scrum’s definition as a clear rule for Scrumists then Feature will always be done inside of a single Sprint which makes the fact that there was ever a debate on which Sprint components get visualised a little strange. Regardless, the whole concept of pulling in a Sprints worth of work and progressively demonstrating delivery is truly magical.
Sprint goals. I have mixed feeling on this concept. The sprint goals for me should be “get through all the work that we pulled in at the start of the Sprint”, after all, it is about working software. To have a meta-goal I feel muddies the waters. Deliver to commitments. If the above references to sprint goal is purely to deliver the features that were committed then I have no problem with it – I just hear various interpretations of this around.
A Sprint is a sacred timebox. I am confused by Scrum.org’s recent definition. It seems to elude to the fact that scope can just be added and removed by the Development Team without concern. If it is talking about exceptional circumstances whereby the team finishes all the committed to features then that is fine, but change inside of the iteration should not be a norm. It is a timebox to deliberately reach commitments and to push out external factors (such as Product Owners that want change every day).

Burn Down Chart

In the 2007 pdf we have the Burn Down Chart defined as:

A burndown chart shows the amount of work remaining across time. The burndown chart is an excellent way of visualizing the correlation between the amount of work remaining at any point in time and the progress of the project team(s) in reducing this work. The intersection of a trend line for work remaining and the horizontal axis indicates the most probable completion of work at that point in time. The burndown chart helps me to “what if” the project by adding and removing functionality from the release to get a more acceptable date, or extending the date to include more functionality. The burndown chart is the collision of reality (work done and how fast it’s being done) with what is planned, or hoped for.

Incidentally the picture provided within the pdf is of a Release Burn Down not a Sprint.

In both March 2007 and March 2009 the Burn Down Chart definition was:

The Burndown Chart shows the cumulative work remaining in a Sprint, day-by-day.

At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work remaining to be completed is the cumulative backlog. When tasks are completed as the Sprint proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog decreases, or burns down over time. If the cumulative Sprint Backlog is zero at the end of the Sprint, the Sprint is successful.

The Product Backlog items brought into the Sprint are fixed for the duration of the Sprint. However, the Sprint Backlog may change for several reasons:

The development team gains a better understanding of work to be done as time progresses and may find that they need to add new tasks to the Sprint Backlog to complete the Product Backlog items selected.
Defects may be identified and logged as additional tasks. While these are viewed primarily as unfinished work on committed tasks, it may be necessary to keep track of them separately.
The Product Owner may work with the team during the Sprint to help refine team understanding of the Sprint goal. The ScrumMaster and Team may decide that minor adjustments that do not lengthen the Sprint are appropriate to optimize customer value.

The Burndown Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product.

In September 2010:

A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint.

Within scrum.org the definition is embedded within the Product Backlog definition:

Monitoring Progress Toward a Goal

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.

The ScrumAlliance definition of the moment is again sparse with:

Burndown chart: at-a-glance look at the work remaining (can have two charts: one for the sprint and one for the overall project).

Burn Down Chart results and opinion

Looking over the Burn Down Chart artifact you would be excused to be confused about what is happening with it. First it was just a Sprint Burn Down, then it was Sprint and Release Burn Down, then it was for scrum.org back to just a Sprint Burn down and Scrum Alliance have it as both. It explains why there is so much mixed information and approaches in the community.
Personally I have always disliked how both the Sprint Burn Down and the Release Burn Down have, for lack of a better term, burnt down. To easily differentiate the two I have always made the Release a ‘Burn Up’ chart. It also tends to work better burning up then down due to the way the scope line changes.
Scrum.org’s removal of the Release Burn Down (Up) is strange. It is explained in their recent FAQ but if I was going to choose between the two and which one was more important I would have put my money on the Release Burn Up. When you have a good wall with all of your cards on it, it is pretty easy to see at any point in time whether you are going to achieve your Sprint commitments. With a list of Product Backlog cards on the wall it isn’t as easy to see whether you are going to meet your Release commitments. Some would say that the Release is impossible to commit to. Try seeing how easy that is to say when you are a Vendor. What the Release Burn Up does is demonstrates whether you are on track or not based upon current achieved velocity and predictive velocity. You can have conversations earlier about the scope, about the time and about the cost of the project.

Anything else?

I feel a few crucial artifacts are missing. There is nothing about where Business Cases fit into this picture. There is nothing about the conversations that need to be made about what is more important for the Product Owner – scope, time, cost or quality (some would argue quality is non-negotiable). Admittedly this is something of an organisation’s governance process and could be seen to be irrelevant but for some crazy reason in most places where I see Scrum being applied at the enterprise level these basic governance artifacts are one of the first things thrown out the window because ‘Scrum says we don’t do that stuff’.

With one more blog to go in this series, we have seen how Scrum has evolved over the years, soon we will see how it hasn’t.