December 6, 2010

Intro to Scrum Part 3: Raiders of the Lost Scrum Artifacts

 

In part 1 of my introduction to scrum series, I talked about the difference between plan driven and value driven. In part 2 of the series I talked about the scrum team. In the last installment of this series, I want to talk about the artifacts of the scrum process.

This is not a complete list, but the following artifacts are the main ones:

  • Product Backlog
  • Acceptance Criteria

Product Backlog

The product backlog is a list of all the work (or story cards) that the team must work on. This is essentially a list of needs/wants for the product that are constantly prioritized. This is the list of solutions that customers, sales, etc. want in the product. Each story card in the backlog is expressed in a way so that it provides an increment of value to the customer. To provide that increment of value to the customer, the story should be a vertical slice through the product.

Each story should fit under the acronym INVEST.

INVEST stands for:

  • Independent – The user story should be self contained, in a way that there is no inherent dependency on another story.
  • Negotiable – User stories, up until they are a part of a sprint, can always be changed and rewritten.
  • Valuable – A user story must deliver value to the end user.
  • Estimable – You must always be able to estimate the size of a user story.
  • Sized appropriately – User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable – The user story or its related description must provide the necessary information to make test development possible.

Backlog Sizing

Sizing the backlog is a measure of pace at which the scrum team can deliver the items in the product backlog. People are not good at estimating work. We all know how terrible we are at accurately estimating how long something will take us to complete. People may not be good at estimating, but we are great at comparing items. For example, we can look at two recipes and tell which one is more complicated to do without having to be professional chefs. Sizing the backlog is all about deciding the complexity and amount of work, not how long it will take us to do the work. What you must realize is that sizing is not equal to estimating.

Some may ask, how will I know how long something will take. Well, you can derive how long something will take to complete after something has been estimated.

To better explain this I want to talk about a dirt pile.

Say you went to Lowes, and bought a truck load of top soil for a garden you are creating in the back yard of your house. You wake up the next morning and see that they delivered the top soil, however, instead of putting the dirt in the back yard, they dump it at the end of your driveway. Now, you need to get the dirt to the backyard and you go out and call three contractors to come and give you estimates on moving the dirt pile to the back yard.

The first contractor comes out and looks over the dirt pile, looks in the back yard, and tells you it will take him a day to do the job. He explains that he has old rusty wheel barrels and a scrawny kid to help him so it will take him all day to do it.

The second contractor comes out and looks over the dirt pile, looks the back yard, and tells you it will take him a half day to do the job. He explains that he just recently purchased new wheel barrels that are not rusted out and the local high school varsity football team is working for him that weekend. With all the muscle and new wheel barrels it will only take him a half day.

The third contractor comes out and looks over the dirt pile, looks in the back yard, and tells you it will take him 1 hour to do the job. He explains that he owns a bobcat and with the heavy machinery he will have it done in no time flat.

What you see in this story are three people with three different estimates, but what did not change in all of this? The size of the dirt pile. No matter who was doing it, the dirt pile never changed, even though the time estimates did.

Acceptance Criteria

Acceptance Criteria is essentially a clarification of the story. Acceptance criteria gives the developer a set of markers the must be completed before the story can be considered done. With this in place, a developer has a great starting point in which to write automated tests or even use test-driven development (TDD). In this way, the developer is creating something that the customer needs/wants with the understanding of how the customer will use it.

Another benefit from acceptance criteria is when the feature cannot be completed in an iteration, the team can use the acceptance criteria as a tool to see where the team could split the feature between multiple iterations.

Conclusion

This is just a brief overview of some of the major artifacts of a scrum process. Here are some links if you want more information about these artifacts.

1 comment:

  1. Oh I think this blog is about the software development models. I once wrote on agile, waterfall model etc but I don’t think I ever read anything on scrum. Thanks!

    ReplyDelete