User Stories defined - notes from the XP forum

I was recently following a thread on the XP forum and one of the responses from Ron Jeffries is worth repeating here for you all to read.

 

"

Um, yes. Or as someone put it long ago, a user story consists of ...
Card
Conversation
Confirmation

The card is just a token used to pass around if one estimates, to
hang on the wall as something to be done, to move around the status
board, and so on.

It is in conversation between PO and team that the team learns what
is really meant. It is here that much of the creativity lies,
converting what the PO originally thought she wanted into the best
idea the team can come up with.

Confirmation, in the most productive teams, consists of concrete
tests, or checks, that show when they pass that the software does
what was agreed it would do. Fastest and most reliable development
seems to happen when a very high proportion of these checks are
automated.

[Some people have the impression that a user story is only #1 or
only #1 and #2. I don't agree, but that's another topic. I don't
think any of the 3 MUST be fully documented, but I do believe all
of the 3 should be well communicated to the dev team.]

Yes. The point is communication. The card serves as a point of
focus, and a status marker. The conversation builds common
understanding and agreement, the confirmation contains the details
of the agreement.

Your detailed test examples are right on point to the original
questions. The one thing that I would add is that it is perfectly
fine to write these story ideas on cards associated with the story,
or on a sheet of paper. The probably do not to be documented further
within the team, and there should probably be no one outside the
team who needs that level of detail.

If the tests are going to be automated -- and generally I recommend
that -- then the test itself serves as perfectly adequate
documentation, especially if written in a FitNesse table or a system
like Cucumber. If the tests are going to be done manually, first go
back to the previous sentence. If there are still tests that need to
be done manually, it may be worth writing them down in a test book
so that you can be sure to do them again, and again, and again, as
regression tests ... which is why automation is so important.

You recommend Mike Cohn's book, and it's definitely a good one. It
is possible to get the impression from it that you should do
everything in there, and it's probably best to do as little as
possible. Start with Card, Conversation, Confirmation. Then, for 99
percent of teams: stay there.

If you're interested in sources, here's an early description of the
ideas, and a darn good one if I do say so myself:

http://xprogramming.com/articles/expcardconversationconfirmation/

Ron Jeffries

 

"

Technical stories - are they included on the backlog?

If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.

What's the ideal sprint length

Introduction

I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly. As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.

Sprint start and stop days - what's best

Firstly, let me state that it is imperative that sprint lengths remain consistent. By all means experiment with 1 week, 2 week or 3 week sprints but once you have figured out your sweet spot, stick to it. This is important to setup a rhythm in the company. However, the question is what days are the best days during the week to start and stop sprints. Until now, I have been a big fan of Monday starts and ending Fridays. It seems to be a natural cadence and the days are logical transition points.

However, this week, there was discussion on the Scrum development forum and a number of folks are in favor of starting on Thursday and ending on Wednesday. Reasons given are as follows:

• There are often holidays on Mondays and Fridays which interrupt the cycle and therefore the rhythm.

• If sprints are a little behind and you end on a Friday, it will force teams to work on the weekends -- generally shunned upon by the Agile community.

• On Fridays, folks generally tend to glide through the demos and retrospectives and as a result there is a drop in productivity.
• Team members work from home on Fridays.

The right answer, let the team decide.

Certainly school for thought. I have to give this a try.

What's been your experience?

Jack

What is a Spike in Scrum

This question comes up time and time again and the Spike is often confused with the Tracer bullet. Adam Sroka posted a great explanation of the difference between the two on the Yahoo Scrumdevelopment group . So I am quoting Adam verbatim here - thanks Adam.

"The Pragmatic Programmers described something called a "Tracer Bullet" which:

1) Is an experimental solution that cuts through all the "layers" of
the architecture.

2) Is not necessarily time-boxed.

3) Is not intended to be thrown away.

Eric Evans talks about "Thin, vertical slices," which are the same as
Tracer Bullets.

A Spike Solution:

1) Is an experimental solution that cuts through all the "layers."

2) Is necessarily time-boxed.

3) Is always intended to be thrown away.

The reason for the distinction, IMO, is that the "tracer bullet" or
"thin, vertical slice" model is how XP teams normally work. A Spike is
an exceptional way of working when we feel we don't have enough
information to give the customer realistic expectations. The goal of
the Spike is to establish those expectations."

Spikes are a really good way for teams to figure out stuff that they don't know and need to know in order to understand the complexity so that it can be properly estimated, or quoted on or simply to find out if something is technically possible or not.

Do you even need a product backlog?

A great question was posted on scrumdevelopment group, worthy of discussion. The question posed ...

Summary

Their business moves very quickly and, more often than not, any stories that enter a sprint will have been thought up and written up maybe only two or three days before a meeting of the stakeholders and the product owner to decide what the priorities are. Anything that doesn't make it into the list for them to estimate and add to the sprint will go on the product backlog, but will generally not be looked at again for a while, if ever.

Question

To this end, our backlog is ever growing with stories that, in all likelihood, we'll never work on. Based on this, should we even bother with a backlog?

Response

Long backlogs in Lean thinking represent waste. Especially given the picture painted by this use case. Long outdated product backlogs means someone in the organization has to go through it and  keep it groomed. The longer the backlog, the longer the time required to keep the backlog updated and if it's really ever used, why bother. Important requirements will always surface again.

I personally hate not recording stories as I am always concerned that a great idea will just get lost and forgotten about. But this does lend to wasteful behavior and work.

In this scenario, it's seems like their just-in-time story elaboration is working well. So I would be inclined to recommend that they drop the notion of a product backlog. Or perhaps triage only really high priority ones onto the backlog.

Thoughts?

Jack

Remote contract workers

A question posted this morning on one of the Yahoo groups ..

" We have a Scrum team in the Silicon Valley and two contractors who work with us remotely. Although they are proficient at what they do, it has been a challenge to get them (understandably so as contractors) to be apart of the team. We have two main issues:

1) They are contractors and don't see Scrum as more than just something to do to
keep a contract.
2) Daily meetings and full conversation required for communication saturation
are next to impossible over the phone (and really poor quality, unreliable Skype
video), and despite our efforts there is a disconnect and a lack of
effectiveness felt by everyone.

State of Agile

Introduction

Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

Stories - how small is too small

Today over on the Scrum Development forum a question was posted by a member. They have a situation where they have mixed some small stories with some larger ones. And the larger one is LATE - Really late. It's now been pushed into the 3rd Sprint and according to her it's still tight. So now they're faced with a situation where the smaller stories that are done can't be deployed as they never branched the code.

I find it alarming that folks can't break user stories down further. So many folks say you can't do it when over on the XP forums they're all working with really small stories so much so that they don't even bother with tasks any more.

The 7 Software Development Wastes - Lean series Part 7 - Defects

Introduction

When one looks at all the wastes, defects has to be the most obvious one. The cost and repercussions of finding defects varies depending on where in the cycle they're found. Defects found early on in the development life-cycle are way less costly to resolve than defects found later on in the cycle; the most expensive being when applications are already in-production.

Additionally, depending on when the defects are found, defects can and do trigger other wastes like task switching, relearning etc.

Defects can be very costly for an organization. So the trick with defects is that you need to 1) Prevent them from happening in the first place and 2) Find and fix them as early in the development life-cycle as possible.

So what can you do to prevent them from happening in the first place?