Agile Release Planning – some questions

QUESTIONS:

Hi Joe,

I’ve read through your book [on Agile Release Planning] and want to say that it was a great review of our Friday session, I enjoyed your clear and concise language, and am sure this will make an excellent resource.

But there are still a few things that are unclear to me; it may be misunderstanding on my part, or perhaps just inexperience with the process.

When you have some time, perhaps you could clarify, or point me to a resource.

1. Are acceptance criteria and DOD the same thing?
2. page 52, last sentence on the page ‘That work represents all the bad news getting better with age…’. I thought bad news always gets worse with age.
3. I’m still not clear on DOD. Perhaps I just need to DO this a few times before I understand.
4. We never really talked about breaking down the stories into work that could be done ‘today’ (what we say at the Daily Scrum that we will do today). Do you know of any resources where I can get more information on this?
5. page 89, last paragraph. I’m still not clear where the black zone is on your chart.
6. page 92, under ‘Comments’, you talk about reviewing the ‘acceptance criteria’. Is acceptance criteria the same as DOD?
7. page 93, 2^nd bullet point –Enabling Spec – this is a new term that we didn’t talk about in the course – who does this and when is it created?

Regards, Carol  [Slightly edited, some things left out]

ANSWERS:

Let me attempt some relatively short answers to your questions.  Certainly longer, and maybe therefore better, answers are possible.  And of course the best answers depend on a better understanding of where you [or Carol] are [is] coming from than I probably have.  But, here goes.

• Acceptance criteria and DOD.

The way I use the words, they are notably different.  This is a common question and a common confusion.

Acceptance criteria: I use this phrase to mean (usually) the 4 or 5 specific things that must be ‘done’ for a specific User Story. So, each set of ACs are specific to one story.

Definition of Done (DOD): I use this to mean (usually) the ONE DOD that the Team has and that applies to all stories. Examples of items in the DOD:
– coding
– automated functional testing, and all bugs (associated with a story) will be fixed
– PO review, and any issues fixed

The DOD tells us when we score the story points.  When all the items in the DOD are ‘checked off’ for a specific user story, then we ‘earn’ the story points as part of the velocity of that sprint.

Key Difference: Looking from the point of view of the Product Backlog — there is only one DOD (that applies to all the stories) and there is one SET of ACs for each user story (so, many sets of ACs).

A guess one other difference might be mentioned now.  The initial DOD should be created ‘up-front’.  The ACs for a given story….must be created at least before that story goes into a sprint.

• “the bad news getting better with age”

I told you a million times I never exaggerate.  And I am never sarcastic.  Seriously: yes, I meant exactly the opposite of what I said.

• DOD

As Yogi said: “In theory, there’s no difference between theory and practice.  In practice, there is.”

• Breaking work into small chunks that can be done each day

Wow, I hope we talked about it then! But maybe you are not connecting the dots.  (Or maybe I forgot to say something in your course.)

Here’s another way of saying it.  We want the stories to be small.  Usually I do the penny day to reinforce that idea.  Also, for a long time I have been making this ‘smallness’ concrete by saying that you must have at least 8 stories in a 2 week sprint, all pretty close to the same size (about the same number of story points).

Next, we usually want the Team to ‘do real work’ in 2 or 3 teamlets (a teamlet is one or two people working on (mainly) one story at a time).  (Yes, Virginia, teamlets can be flexible and adaptive during the sprint. Teamlet is NOT nearly as solid a concept as the Team idea.)

So, again, for a teamlet, almost always a story takes more than 1 day to complete. (You can have really really small stories that can be completed in a day or less by a teamlet, and some teams like this, but for beginners I think this is too hard.)

So, at least for beginners we have in Scrum the task concept.  Tasks are a breakdown of a (sprint-sized) story, and we do that in the Sprint Planning meeting.  And, in the Daily Scrum, each day a person can say “I will get task X done today and I will also work on task Y”.  And each task is small enough (we suggest most 2-4 hours) so that fairly reliably, that task can get done in a day, even with all the normal stuff hitting the fan. Or, as we say, usually even if all hell breaks loose.  Or (I hate to shock you) even if humans get distracted a bit.

And this allows, in the next Daily Scrum, for the team to see how much progress was made (or maybe not made) on tasks that ‘should’ have been done the day before.  (And, of course, just about every day we have some small failures, but in general most of the tasks actually did get completed.)

Other resources:  Hmmm.  Well, lots of people talk about task break downs.  But, no, nothing comes to mind as an obvious ‘resource’ that you must read.  Maybe if you reacted to what I just said, tried to do that in the Team for a while, and then told me what your team’s real problem was, I might suggest something.  “Try it; you’ll like it.”  But you’ve heard that before.

• the black zone

Well, this is awkward.  I see that the picture is supposed to be in color, and only is in black and white.  Let me get THAT fixed.

For now, I hope you recall in class that, roughly, the bottom part (of the picture on page 89 and that I draw in class) shows two sprints, the 3 main meetings, and the squiggle, which represents the real work and the Daily Scrums of each sprint.  That is what I mean by the black zone, and it is (usually) drawn in black.  (Sometimes blue, if I cannot find a black marker fast enough.)

Above that I draw ‘the parallel universe’ of Release Plan Refactoring in red.  (I see now in the PDF I have that the ‘book’ does not show RPR in red.)  And, I call RPR ‘the red zone’ to contrast it with ‘the black zone’.

Help enough for now?  Let me see if I can get LeanPub to publish the real picture in color.  Thanks!

• reviewing the acceptance criteria in the Long Term Release Plan Refactoring meeting

For new readers, I guess I must at least quickly say that ‘release plan refactoring’ is (probably) roughly what you know as ‘product backlog grooming’ or some similar phrase.  And I speak of a long-term RPR meeting and a short-term RPR meeting each sprint (assuming a 2 week sprint).

So, in the L-T meeting, I was suggesting that they create or identify or review the acceptance criteria for stories that will be going into sprint a bit down the road.  My suggestion is that identifying the ACs for a story is usually the beginning of (later) pulling together ‘all the details’ we will have for that story.

Let me add that in some sense they also review the ACs for a story in the S-T meeting as well, to be sure that they still ‘make sense’ in the new new situation. (Things can change, and people can suddenly see new things. Never forget that.  It’s ok for knowledge workers to get smarter. To err is divine, to forgive is human.)

• Enabling Spec

Hmmm.  Well, depends on exactly which course.  Virtually always (I think) I talk about the Enabling Spec, but often I do not use that phrase.  KISS for the beginners, you know.

I definitely want to talk about the ‘ready ready criteria’ (sometimes called the DOR — definition of ready).  I think I do always, but maybe not ‘always’.

Enabling Spec is a phrase the Jeff Sutherland uses, and has written many blog posts on.  So, you might want to click on this link for his blog.

A few lines later in the (my) book, I describe the Enabling Spec in these words:

The Enabling Spec is just enough, just-in-time documentation.
(We are not worried now exactly how the ‘documentation’
is instantiated, e.g., maybe on paper or maybe electronically, etc., etc.)

At least conceptually, there is one Enabling Spec for each User Story.  So, if it were in paper form, maybe a half-sheet, maybe 1 or 2 or 3 pages, with picture(s) and a list(s).  Maybe the pictures are hand drawn, quickly.  Your team has to define exactly what it should be for them and your work.  But, like Goldilocks, not too much, not too little, just right.

One way of putting: “There is no BS, but we have all the info we need for a story to build it right the first time.  Or at least we thought we did when we started the sprint. Usually we a few more questions later, usually small ones.”

***

Hope those comments help.  Please ask more.

If you are more interested in this topic, please read my book (see link at the top of this post).  (Everyone who has taken my course gets a copy for free… if they download within a week or so.)  And/or, you can read lots of related blog posts here for free.

 

« « Five Characteristics of Successful Teams || Question: Is Scrum all or none? » »