Advanced Topics In Scrum

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:

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

• Project Management is mainly about “managing the work” or stimulating the environment so the work gets done with minimal telling people how / what to do.
• Source Control if it’s only one file then, I don’t need it of course it is always more than that as soon as it goes over 100 files it becomes a necessity.
• Build automation (and repeatable automated configurations as a whole) shows up after source control and becomes a necessity around 500(pick a number that you think you will go crazy at) items or so. It is a number thing but, I can get by longer without repeatable automated configurations than I can without Source Control.
• Test Automation this shows up as needed after 1000 plus code files. Test automation is all about feedback. When I say feedback it assumes people are already thinking in terms of interface design “start with the end in mind” if not then TDD/Unit must be purused because people are missing critical thinking skills.

• Incremental Funding Approach (IFA)
  • Should we spend any more money?
• Minimum Marketable Features (MMF)
  • How much and what product do we need to win?
• Minimum Releasable Features (MRF)
  • What can we release so that we can satisfy demand now and get more feedback?
• Minimum Demonstrable Feature (MDF)
  • How can we show case the product and thereby get valuable feedback early & often?

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

This is perhaps one of the most obvious yet, continually overlooked rules. Visibility is key to getting the emergent behavior we would like to see on teams so that we don’t have to resort to task assignment. For conceptually heavy work this is especially true. Transcending this pattern requires a mechanism to make things visible.

For a group of people, when the visilbility of the work between is poor or hidden then the  collaborative interactions are correspondinlgy very  poor. This holds especially true for work that is largely coneptual in nature. 

By making things visible people have a chance to self organize to the work and pitch in without being told. They work together collaborative to do the job. Making things visible in the right way is the challenge of management. 

No wasted words (that’s what you get when your friend is a mathematician), this is a 1st draft of an excerp from our book written by Dan. It offers a very quick, powerfully concise summary of Scrum.

Download Scrum In A Nutshell

excerpt… “While the Stakeholders are the most important people for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is held accountable by them for the success of the Team. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.”

• How much is the PO truely seprate from the team?
• Is there a single wringlable neck?
• Is the team / PO a symbiotic ecosystem with a centralized model for detemining direction? thoughts?

This is free for you to consume. It is our hope that you will provide comments and feedback. Those that do can register on our community site and provide constructive comments. They will be acknowledged. We will use your comments to evolve the explanation of thought here or clarify ideas. As you read, hold on to your shoes because each sentence is loaded with deep layer focused meaning and if you skip around reading this will hurt your understanding. 

As a trainer/coach and a member of the agile community. We
have tried that and shown it to be the wrong strategy.

Product Development is a much better choice of words.

Here is one reason why… If I say software development the first word
that comes to mind for most people is code. That means if you write
code scrum/agile is for you and if you don’t it does not apply.
Repeatedly I have seen organizations become crippled in their
application of agile from that simple (seemingly small innocent ) turn
of words. XP, another agile practice got much of it’s bad rap simply
because it was code/software centric in it’s wording.

For much of the reasons I outlined above and for some others I have
not we don’t say software development. Instead we use the word product
development which broadens the context in an appropriate direction and
allows for better balance and understanding to occur in practice.

Sharing and communicating these concepts without causing people to lock
them down is very hard and requires extreme attention to practical
use. Concepts are not words but words are all we have so chose them
carefully and then watch for understanding.

Limiting focus to software development and that language will quickly
cause loss of balance in my experience.

A few years (about 6-7, I think) I introduced the team “done/done/done”
into agility in order to describe what “done” meant in an agile setting.
It is now pretty established the “done” is a HUGE concept in scrum, but
at the time we were just figuring it out. My thinking at the time was
that a Story was “done” when it was “Done/Done/Done”, where the three
“dones” meant (coded/verified/validated). That is:

* Coded – it works on the developer’s box
* Verified – Unit tested and they work on Integration box
* Validated – accepted by ProductOwner as being what was needed

Later on a fourth “Done” was added for “Production Ready”, which meant:

* Production Ready – all additional stuff was there, like
documentation, training for users, etc

Now, I still like the four “dones”, but have a slightly different focus.
Since Stories are now well-defined bits of work, with well-defined
definitions of done, there is no longer the subjective third “done” for
them. The Product Owner no longer gets to decide if it is what is
needed, the story is defined to be done once the acceptance criteria are
verified. So there is not a hierarchy of things we do:

* Stories get “Done/Done”
* Features get “Done/Done/Done”, and we don’t know how many stories
this will take
* Products get “Done/Done/Done/Done”, and we don’t know which
features this will take, or how many stories it will take

This new way of looking at things shows us what is really going on.
Within the team’s work there is only tactical agility, where the team is
being agile in figuring out how to meet its story’s acceptance criteria.
There is low-level strategic agility where the PO is deciding which
stories to deliver for each feature in order to provide the value (for
that feature) that is needed. And there is high-level agility where the
PO is deciding what is the “releasable feature set” necessary to
actually be able to put this thing into production. Three different
levels of agility, three different sets of stakeholders, three different
levels of abstraction and questions to ask.

Dan Rawsthorne
dan@danube.com