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

Re: [scrumdevelopment] How to handle partially completed stories

Expand Messages
  • RonJeffries
    Bas, ... It will if you let it. It will not, if you do not let it exceed 2 days. The programmers are going to do something every day. All they have to do is
    Message 1 of 83 , Dec 28, 2011
    • 0 Attachment
      Bas,

      On Dec 28, 2011, at 1:10 AM, Bas Vodde wrote:

      I'm not arguing about whether you can split up stories in customer-centric stories, just arguing the size of these will probably exceed 2 days (but ought to fit in a 2 week sprint).

      It will if you let it. It will not, if you do not let it exceed 2 days. The programmers are going to do something every day. All they have to do is make that something visible. Whether that's a phone ringing, a dot on a screen, a voltage on a wire, doesn't matter. 

      It is easier to point to a field on the screen, than to e.g. discuss parts of protocols...

      I don't see the point of this. I would not split a story into 1) discuss protocols, 2) do something else. That would not be a business-focused split. Let me give an example:

      We were building a numerical device, a robot arm that moves objects from place to place. To do this, the device has to sense where the objects are and determine their size. It then positions the arm above an object with the hand open, lowers the arm till the hand surrounds the object, then closes the hand. It then raises the arm, moves to another position, lowers the arm, releases the object, then returns the arm to some known standard position.

      First split: break out determining position from moving the arm. We decided to do moving the arm first, because it's visible, and once we can move the arm, it will be obvious whether sensing works: just move an object and see if the arm can find it.

      Our arm had a rotating pivot at its base, a "shoulder", an elbow, a "wrist", and a claw. We want the wrist to move so that the claw always points down. It may be necessary to rotate the wrist to grab the objects. We split that out into a separate story. Our starting story was sliced to deal with objects of a known size (claw grasp amount), position, and orientation.

      The primitive operations already implemented on the robot included setting the rotator thing to an angle, the shoulder angle, the elbow angle, the wrist angle, and the claw opening. 

      Suppose we had to implement these primitives, in a really early robot arm story. The articulated points are of course controlled with stepper motors. The very first story is to make motor zero step at some fixed rate. This amounts to a handful of lines of code, executed on a timer. It takes a morning to do.

      The next story at this level might show that we could move a second motor step at a different rate or direction, or might show that we could position the first motor to an absolute position.  Same afternoon, easy. Two days, trivial, with time out for plenty of snacks.

      But we didn't need to do that now, we had the primitives.

      Very first slice we did was to set the rotator, shoulder, elbow, wrist, and claw to the rest position. We did this by deciding the angles of the motors: 0, 60, 30, -30. This makes the arm make a nice equilateral triangle, since the arms are equal length, with the hand dangling straight down. To  make this happen, we need four calls to the motors, all hand calculated. Type in, compile, load, run. Done. Took less than a day.

      Then we moved the arm in and out, hand at a fixed height. This amounts to an equal adjustment on the shoulder, elbow, and wrist angles.  You have to get the signs right, which takes about a minute of drawing on the whiteboard. Type in, compile, load, run. Now the arm moves in and out whatever distance we picked. Again, less than a day.

      Then we added in rotation, just setting the rotator to various angles. Now the arm moves in and out and side to side. Took a few minutes on top of the previous capability.

      This left us with the ability to position the arm to any x and y location within its reach with a little elementary trig. We decided to use a fixed motion speed, directly toward the point. Trig to get the vector, compute its length, chop it to single step length, move that far in that direction. Not even hours to do.

      Then we added z positioning. Took us a bunch of drawing of diagrams and amounts to adding one angle to the shoulder, then positioning on a slanted instead of flat plane. The code is trivial. The reasoning took almost an hour.

      Now we can position to any reachable point in the arm's range. We put a block at that location, position above it, lower arm, close claw, raise arm, go somewhere else, lower arm, release claw. 

      Object lifted from known position, set down in another. Every step of the way, the arm actually moved, so anyone actually interested can see exactly what we're working on at any time.

      One robot arm, picking stuff up and setting it down. The longest step in there was about four hours.

      In my view, it would be an extremely rare situation where stories cannot be sliced to a couple of days, with very little practice. By that I mean that I have never been in a situation where, at least in retrospect, I couldn't see how to do it. Now that I know that, I just don't stop thinking until I know how to do it before scheduling the story.

      If we took a team who couldn't program in the language, didn't have the hardware, didn't understand geometry, had no compilers, and spoke several different languages, it might take them longer. However, that is not a valid Scrum team. A Scrum team, by definition, must have within it everything necessary to produce an increment of product within the Sprint. If they have that, all they have to learn is how to make their work visible every day.

      Of course, it is "sufficient" in Scrum to accept stories that are one Sprint long. It is also, again in my view, very risky, because when we guess wrong, we tend to have whole stories fail to finish. 

      Everywhere I've been, we could figure out how to get stories down to a couple of days. Once we figure out how, there's no reason not to: we get faster feedback, make the Product Owner and ourselves happy more often. 

      There's no law requiring teams to do this. It just works better, and as far as I can tell, you could make a fortune betting a dollar against ten that it is possible in a randomly selected domain. Well, you could if a dollar was worth anything.

      Ron Jeffries
      I'm really pissed off by what people are passing off as "agile" these days.
      You may have a red car, but that does not make it a Ferrari.
        -- Steve Hayes

    • 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.

        Wouter

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

        Ron,

        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. 

        Conclusion

        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. 

        Regards,

        Ron Jeffries
        www.XProgramming.com
        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.