This is my first attempt at making a Livestream cast with Video. The talk is on Scrum and is really a primer or refresh of what Scrum is. There will be several more videos coming that will start to make up a knowledge track that you can follow through.
I hope you enjoy. Please leave a comment on your experience.
Look for more videos coming soon from a wide audience of practitioners, coaches and trainers.
First of all, let’s talk about capabilities. Basically, a capability is something that a stakeholder has asked for; and it is something that provides value for that stakeholder. When it comes to be software products were building, these things are often called features, as well.
Capabilities are the things we talk about with our stakeholders, and we talk about them in the stakeholder’s language. Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.
Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders are thinking in and it’s is what they will use to understand the product we have built.
As we know, stakeholders can ask for virtually anything. Therefore, capabilities can be virtually anything, from small bugs that he be fixed to extremely large wishes and dreams. For example, each of the following statements describes a capability:
What’s important to know about capabilities is that the priorities of the capabilities derived from the stakeholders, even though they may be modified by dependencies that the developers see. Since scrum is all about having a prioritized list of things to work on, we can see that most of the priorities that we derive from the stakeholders.
What we are usually trying to deliver in a release is a releasable capability. This leads to concepts that we find in the literature such as Minimal Marketable Feature (MMF), Minimal Releasable Feature (MRF), and so on. Even though I won’t discuss it, I think that for scrum what we really need to produce is Minimal Demonstrable Features (MDF), as the basic concept of scrum is to inspect and adapt, so we need to produce capabilities that we can demonstrate in order to get feedback.
The purpose of scrum is to develop product, often software and other ancillary products based on items in the backlog. In order to talk about this work we use lots of different terms when talking about backlog items, such as capability, feature, story, task, and so on. In this chapter we will define the terms that we use in this book, and have some discussion about the differences and nuances.
In particular, we will discuss the following terms: capability, chore, story, epic, and task. There tend to be natural comparisons and pairings in this set; for example, capability versus chore, stories versus epic, and story versus task. Each of these issues will be discussed as we go along.
But first, a quick review of fully know about Backlog Items, or PBIs. Basically a backlog items is anything the lives on the backlog; it can represent work to be done, issues to be discussed, or problems that we have. In any case, a backlog items is a token for future conversations, that progress from the moment we know about the backlog item until the work it represents has either been completed or discarded.
Short for “Product Backlog Item” – its original name. We keep the “P” because we love Three Letter Acronyms (TLAs).
This was derived from the use of stories, and we think it is a universal concept.
Our Glossary of Agile Terms
Tasks are the actual units of work the team does when working on a story in a sprint. The story is the item of planning and negotiation, but team often break stories into tasks in order to manage their work. We will seldom discuss tasks in this book, as the internal workings of the scrum team aren’t this book’s main focus.
The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.
Another major topic for discussion here is the Epic, which many think is just a “large story.” However, I like to define epic as an item that can’t be committed to by the team. This could be for a variety of reasons, most of which are captured in the acronym CURB:
|
Complex |
The item might be too complex to be understood well enough to be committed to. |
|
Unknown |
Maybe nobody on the team knows enough about the story to even make a guess whether it can be committed to. |
|
Risky |
There are too many unknowns; it is too risky to commit to the story without further investigation or a mitigation strategy. |
|
Big |
It could just be too big to do in one sprint, even though it is well understood. |
In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.
Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.
Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.
Some examples of epics are:
• “We want the system to be able to manage the pilots’ schedules”;
• “We’re going to need to train all our users on this new release”;
• “As a <tourist>, I want to <fly to Catalina for the weekend>”; or
• “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.
The most important unit of work that a scrum team does is the Story. The story is a small unit of work that the team does “all at once” and is used to provide either capabilities or chores. Even though some capabilities are small, and delivered with one story (bugs, mostly), most capabilities are delivered only after the development of many stories.
In general, a story is simply a request for the team to do something of value. This does not mean releasable value; that’s what capabilities are for. It does mean demonstrable, testable, verifiable value, as we need to be able to be able to inspect and adapt based on the results.
A story is an extension of the user story, which was introduced in eXtreme Programming (XP), but we don’t restrict stories in scrum the just the ones that user value. This is why we just call them “stories”, and often add a modifier, like “analysis story” or “infrastructure story” or “development story”.
In spite of the fact that not all our stories are user stories, it is useful to look at the INVEST acronym, which Bill Wake originally introduced to describe “good” user stories:
|
Independent |
Stories should be internally independent during their execution; that is, the success of one story should not depend on the success of another being done at the same time. |
|
Negotiable |
Stories are the negotiation units in scrum. It is stories that are committed to in planning and that are delivered. In addition, the actual content of a story is negotiable during development. |
|
Valuable |
Stories are, by definition, units of value that are requested by stakeholders or team members. The value can be external or external – providing value to stakeholders or to the team. |
|
Estimable |
The team needs to be able to commit to the story, which usually implies that the story’s effort could be estimated. However, some stories are so ambiguous that they must be time-boxed. |
|
Small |
Stories should be small enough that there is little confusion about what they mean, and so they can be completed relatively quickly. I recommend a single focus per story. |
|
Testable |
Stories should be testable; more precisely, each story needs to be verifiable, so that the team can determine when it is “done.” This “doneness” takes different forms for different kinds of stories. |
While the acronym needs to twist a little bit to fit when we expand the concept from “user story” to just plain “story”, the basic ideas are good. Basically, a good story is one that is small and well-understood enough for the team to commit to and not be confused by. If we are talking about functional stories, the definition of “small” the I like to use is “one thread” or “one positive test” or “one state of the system” or something like that. We’ll discuss this concept in the next chapter, when we discuss the definition of “done.”
The concept of the story is both simple and brilliant. What makes it simple is that at its core a story is just a request for something of value, and the purpose of the story is to start a conversation. The story takes the place of a requirement, but it has a completely different tone. Whereas the requirement has the tone “here’s what I want, just go do it” the story has the tone “here’s what I want, let’s talk”. As Alistair Cockburn has said “a story is a promise for a conversation”.
What makes a story brilliant is that not only does it replace a requirement, it also replaces the low-level activity; a story is not only the request for value, it is also the activity, or work, that it will take to provide the value. In practice, this means that as you are doing analysis in order to find requirements/stories you are also developing your units of work. All you have to do is add prioritization, and you’re good to go – your planning is done. Some examples of stories include:
• “As a <passenger>, I want to <be able to select my seat online>, so that <I don’t have to do it at the airport>”;
• “Go talk to the pilots and find out what they think about pilot compensation”;
• “Review the suggestions the pilots have submitted to see if there’s anything cool there”; or
• “I need somebody to spend an afternoon with the pilots, to explain to them how the pilot compensation page works”.
There are other things we want from our stories, as well, and we’ll be discussing them throughout this book. For now, though, this is enough.
I’ve been using and studying scrum ever since I heard about it from Linda Rising 12 or so years ago. At it’s core Scrum is a pattern language (http://en.wikipedia.org/wiki/Pattern_language), and it’s been evolving as people find better ways of doing things, and thepatterns have changed. This post will give a very quick overview of what I’ve seen change. I believe that Scrum has gone through two significant versions, and I’m willing to guess what the next version is. To track these stages of evolution, I’ll number them Scrum I, II, and III and then direct your attention towards the interesting points of evolution.
(Scrum I, Early Scrum, 1995-2004-ish) PO usually external
to team, negotiates sprint backlog with the team. The team self-organizes, produces “done” product, and has a Sprint Review with the PO, who either approves or disapproves the work. The only way to “officially” change requirements in the middle of the sprint is to have an abnormal termination and start over. After the sprint the team (sometimes including the PO) has a retrospective to improve its process, and the PO modifies the release plan.
This leads to a number of Issues/Forces:
- adapting to business changes within the sprint is difficult
- hard to talk to PO for additional guidance during the sprint
- often caused the team to view the PO as “one of them” and not “one of us”
- many teams created a “Product Owner Proxy” who represented the PO day-to-day on the team
(Scrum II, Modern Scrum, 2002-Present) PO internal to team, and negotiates sprint backlog with rest of team. The team (including the PO) self-organizes, produces “done” product that is accepted by the PO along the way. Teams develop various methods for reprioritizing and bringing in new work during a sprint (negotiating techniques, mid-sprint replanning, etc). The Team (including PO) reviews the results with external stakeholders during the Sprint Review and receives feedback that changes the release plan and is incorporated into the next sprint’s planning. After the sprint the team (including the PO) has a retrospective to improve its process.
Differences:
- PO on team
- more in-the-sprint changes to Sprint Backlog
- PO is more a part of the team’s day to day work
- Adaptive Evolution of the Product is finer grained
- Focus on delivery to Stakeholders, not PO
There were/are some Issues/Forces:
- Still not quite adaptive enough for some
- “last few” stories on sprint backlog are always being supplanted by new ones
- Sprint lengths got shorter to allow for more frequent feedback and planning
- can’t make the sprints as short as we’d like to because some stories just “take that long”
(Scrum III (KanBan-ish version), 2007-Present) There is no Sprint Backlog, only Work In Progress (WIP), which is fixed length set of stories currently being worked on. There is still a Sprint, which is a fixed-length timebox that defines the time between reviews, the changes to release planning, and the setting of sprint goals. At the beginning of the sprint the Product Owner negotiates goals for the sprint with the team. The team is constantly grooming and reprioritizing the backlog. When a story is completed, a new one is moved up to the WIP and begun. At the end of the Sprint there is a Sprint Review for the Stakeholders where the completed work is reviewed.
Differences:
- Sprint Backlog replaced by WIP
- because is WIP, stories can go across sprint boundaries
Note that this evolutionary change is much smaller than the former. Perhaps we are converging on a final solution - I don’t know. I have no idea what comes after this. We’ll just have to wait and see what issues come up, and what patterns emerge.
Dan 
The purpose of this post is to consider Four Pillars of Software Development and Simpley Rules 
of course it is always more than that as soon as it goes over 100 files it becomes a necessity. These are all methods to be validation centric. The constant challege in complex product development is to build the right product.
More to follow this thought is still baking
Thanks for all the great feedback.
Here is round 2.
This is close to a done draft.
Please read and comment.
Scrum In A Nutshell - Quick Summary
