Loading ...
Sorry, an error occurred while loading the content.

How to handle partially completed stories

Expand Messages
  • JackM
    We had an interesting Scrum Council meeting today. One of my favourite topics was raised ... how to handle partially completed stories. I have always been a
    Message 1 of 83 , Dec 22, 2011
    • 0 Attachment
      We had an interesting Scrum Council meeting today. One of my favourite topics was raised ... how to handle partially completed stories.

      I have always been a believer of zero credit for partial stories, all the credit in the sprint that it get's completed in. My reason and I am sure others would agree is that this encourages teams to get stories planned in a Sprint completed. i.e. it pushes teams to get stuff done, to size and plan better. All good.

      The other alternative is to award partial points for stories completed. And i believe most agilists (i may be wrong)would prefer not to treat stories this way.

      Interestingly one of my team mates has introduced a slight variant to this and I'd like to hear your opinions on this. I think it has some merit.

      If a team partially completes a Story (lest say it's an 8 point story for arguments sake) in a sprint. The team get's zero points in that Sprint. But for the next Sprint the team determines during planning the size of the work remaining for the story is 3 points. If they finish the story they're only awarded 3 points instead of the full 10 points as originally sized.

      In this way the team really get's dinged for not completing. Overall it lowers the teams velocity. And drives the team hard to get it right the next time. This team has been doing it this way for quite some time and have been rather effective at hitting their goals.


    • Wouter Lagerweij
      Hi Charles, Indeed excellent post:-) I rather think that teams that get Ron involved have already made a big enough commitment to certainly be willing to try.
      Message 83 of 83 , Dec 29, 2011
      • 0 Attachment
        Hi Charles,

        Indeed excellent post:-)

        I rather think that teams that get Ron involved have already made a big enough commitment to certainly be willing to try.

        That said, I do have some success getting teams to start with good Acceptance Criteria and small stories. Not usually at the moment when I suggest them, but with some prompting they do get around to trying it, and the benefits are clear enough that they stick with it.

        Shorter sprints has been much more difficult, though. One team recently started doing one week sprints, and seem to really like it. Usually, though, the organisational impediments (and technical ones) are enough to keep teams from wanting to try.


        On Fri, Dec 30, 2011 at 12:45 AM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:


        Excellent post.  I basically agree with you.  My history of context includes mostly teams that are not yet ready to "do Scrum well", much less "User Stories Well."

        The other challenge I find is getting teams to believe in the value of going down the "Well Defined Acceptance Tests" and "2 day stories are better" roads.  You can explain until your blue in the face that bugs and thrashing are the outcomes of not doing these well, but programmer types are pretty hard headed(me included, as a former and sometimes current programmer).

        I often get this feeling that my status as a consultant/coach/contractor puts me in places that have so many impediments(to "doing Scrum well") that I find it hard to get down the impediment list far enough to get to the ideal 2 day stories. 

        Curiosity question -- when you say "shorten the sprints", do you impose the shorter sprint as coach/SM? or do you try to talk the dev team into it? 

        I've had a little success with the former, and almost none with the latter, but again, my context is skewed to teams new to Scrum.
        Charles Bradley

        From: RonJeffries <ronjeffries@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Thursday, December 29, 2011 4:30 PM

        Subject: Re: [scrumdevelopment] How to handle partially completed stories

        Hi Charles,

        I am restating my position here a bit. I still hold that small stories are better than larger, down to at least the two-day point. I still hold that any team can learn to do it.

        I do want to clarify that not every team is prepared to do it. They need to be doing Scrum well. If they are just barely starting, or are struggling, there are other things they probably need to start with. (The XP practices are a common set. Quite often, it's something more basic, like getting a decent PO, getting a full-time cross functional team, or having a decent definition of done.) These things are Scrum 101, but there certainly are teams who have not yet mastered Scrum 101. Small stories are a 200-level class, maybe even 300.

        On Dec 29, 2011, at 5:24 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:

        I've documented this as a "User Story Pattern", which IMO, is a pattern that is only likely achievable in a certain context.  Here's the pattern (feel free to dissect, I welcome it.)  :-)

        Your delightful article describes the pattern well. You do list a number of requirements, which are pretty good but deserve some comment:

        • Someone needs to be a good story slicer. Yes. Usually takes literally hours to learn how to do this. 
        • PO must be highly available. Yes, always. However, note that slicing is done at Backlog Grooming and Sprint Planning time, so slicing does not really increase the need much.
        • Exponential growth of stories. No, actually, it's linear, multiplication by a small constant.
        • PO must be available for sign-off. Mmm, that's one way. Defined acceptance tests is another and better way.
        • Care must be taken communicating with stakeholders. Wow. That's the first time that ever happened! :)
        • Half-baked stories are a bad idea. Here again, nothing new about that. Whenever we release we will have some work in flight and need to do something about it.

        There are additional requirements that you didn't mention ...

        Why a team may not be "able" to do this: they are not prepared.

        You are quite correct to think of this as an advanced technique. In order to do it, a team will benefit from some things you didn't mention. In general, they need to be doing Scrum well, with such things as:

        • Generally successful Sprints;
        • Engaged PO;
        • Technology stack well in hand;
        • Domain reasonably well understood;
        • Solid code base;
        • Integrated testing, probably including plenty of automated checking;
        • Few handoffs between team members: truly cross-functional;
        • Strong "definition of done".

        These are, unfortunately, things that many teams do not yet have. If not, they need to get them because their absence will show up as impediments or other concerns and we are required in Scrum to remove all impediments. Once they get those things, small stories are relatively easy.

        Results from training

        In our CSD classes, we do half-day Sprints, writing real software, and the teams get multiple stories done per Sprint. They use all the XP practices, often starting with no real knowledge of them on day one.

        In our two-week project kickoff classes, we do two-day Sprints and ship real project software in every Sprint.

        Results from existing Agile teams

        I have worked with many would-be Agile teams, in many domains, over a decade and a half. As far as I can recall, none that tried were unable to get stories that small, and all of them found benefit to doing it.

        It has never taken more than a day to show them how to do it. Usually it takes a willing team only one or two examples to move from "couldn't happen here" to "oh, this is easy".

        Results from personal experience

        Chet and I generally do two hour stories, but sometimes they take four. We apologize for that.

        Personally, I have worked in every domain from nuclear weapons targeting to payroll, from compiler writing and database to text processing, and practically every programming language on earth. Um ... APL, Basic, C, C++, Delphi, FORTRAN ... damn, no E ... you get the picture.

        In all those domains, and all those languages, I could today work two day stories, and I would. I wish I had known to do it all those years ago: it would have changed my world to include many more successes. 


        My best guess is that it does take a very special context to work stories of this size. The team, including its teacher and coach, must be willing to try.

        After willingness, the team needs to be gelled, working together, doing Scrum fairly well. They need to be able to deliver their selected stories in the Sprint with reasonable success.

        Note, however, that there are two well-known "tricks" for helping a team that is having trouble getting done in their Sprints:
        1. Shorten the Sprint. Yes, shorten.
        2. Do smaller stories. Hey, look! Smaller stories help you get done!

        That's my finding, that's George's finding, it's the finding of a whole pile of people doing this stuff, and we're sticking to it.

        I will of course be happy to discuss any specific issues here, and to help a well-functioning team figure out how to slice their stories thinner. 


        Ron Jeffries
        I try to Zen through it and keep my voice very mellow and low.
        Inside I am screaming and have a machine gun.
        Yin and Yang I figure.
          -- Tom Jeffries

        Wouter Lagerweij         | wouter@...
      Your message has been successfully submitted and would be delivered to recipients shortly.