As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?

1. A placeholder story is a sign of sloppy planning
2. All work should be known ahead of time and planned during sprint planning
3. Yes, this allows the Product Owner to dump things into the sprint as needed.
4. Sometimes we have a history of unexpected bugs/issues of handle it now. This allows us to track how much of that is showing up and leave some slack for when it does.
5. We often have work we know we will have to do but, don’t know what it is yet.

Comment: This is a way to track how much unknown work is showing up and manage the amount by triggering a conversation when needed. One of the most common issues for scrum teams is what to do about work that we expect to have to do during a Sprint, but don’t actually know the details about yet, such as bugs we have to fix in existing systems, or expected sales support efforts. Using Place holder stories is a a method to manage these “known unknowns”.

Comment: After a Story is committed to, the Team (with the PO in the lead) has the option to reprioritize the Story list, and the Team takes the next one to consider. Once again, the Team comes to the “doneness” Agreement and commits to adding the Story to the list of already-committed-to Stories. This process is repeated until the Sprint is “full” and the Sprint Plan is complete.

Comment: The Team may not be able to commit to a story, or might noteven be able to agree on “done.” This makes the story in question is an epic, by definition, and the Team must decide what to do. Typical choices include committing to an Analysis Story to figure out what to do about the epic, or extracting a smaller story from the epic to do instead (putting the remainder back on the backlog), or skipping the story altogether and moving to the next one. Bottom line: We need a sense of movement to understand what the team can and cannot do. Biting off chunks of work that are too large obscures movement and makes throughput / velocity that much harder to understand. Use the team’s ability to commit to understand the work that the  story represents.

Comment: Changes to work forms an interesting tension.  At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change to reflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new  stories that were  suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at  expressing work they can do and following through on a commitment.

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:

• Remove the extra linefeeds in the presentation of the list of flights on the “Choose a Flight” page (a bug);
• I want to be able specify that I need a special meal for my flight (a new feature); and
• Make it faster (an extremely large, ambiguous request).

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.

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.

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:

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.