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

Undone Work

Expand Messages
  • chuckspublicprofile
    The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with Undone work.
    Message 1 of 5 , Jul 1, 2010
    • 0 Attachment
      The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with "Undone" work.

      http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit

      Does anyone actually use that strategy?

      Outside of release related activities (performance testing, security, stability, etc), does anyone actually split off shippable functionality from a backlog item at the end of the sprint and apportion the estimates to the "done" part and the "undone" part?

      Other than describing release related activities, this last 2.5 paragraphs really bothers me. I try to coach my teams to ALWAYS get to done on a story. I encourage them to not sweep technical debt or bugs or undone work under the rug until later.

      Just curious how anyone else interprets or applies this part of the Scrum Guide.

      Charles Bradley, CSM
      Scrum Coach
      Denver, CO
    • Andreas
      Hi Charles, in my experience it is not unusual to start with an incomplete Definition of Done because the team can absorb only a certain amount of (process)
      Message 2 of 5 , Jul 1, 2010
      • 0 Attachment
        Hi Charles,

        in my experience it is not unusual to start with an "incomplete" Definition of Done because the team can absorb only a certain amount of (process) changes. Stories should be "done" in this regard at the end of sprint, and over time the Team should strive for a more complete DoD. I think it's a good idea to capture stuff for release/hardening sprints in the backlog to improve release/roadmap planning.

        YMMV, of course.

        --Andreas

        --- In scrumdevelopment@yahoogroups.com, "chuckspublicprofile" <chuck-lists2@...> wrote:
        >
        > The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with "Undone" work.
        >
        > http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
        >
        > Does anyone actually use that strategy?
        >
        > Outside of release related activities (performance testing, security, stability, etc), does anyone actually split off shippable functionality from a backlog item at the end of the sprint and apportion the estimates to the "done" part and the "undone" part?
        >
        > Other than describing release related activities, this last 2.5 paragraphs really bothers me. I try to coach my teams to ALWAYS get to done on a story. I encourage them to not sweep technical debt or bugs or undone work under the rug until later.
        >
        > Just curious how anyone else interprets or applies this part of the Scrum Guide.
        >
        > Charles Bradley, CSM
        > Scrum Coach
        > Denver, CO
        >
      • Michael James
        Ah, the morning after pill. This is in tension with Ken s old slides, which state[d]: ScrumMaster must prevent demonstration of undone work. I think Ken
        Message 3 of 5 , Jul 1, 2010
        • 0 Attachment
          Ah, the morning after pill.  This is in tension with Ken's old slides, which state[d]: "ScrumMaster must prevent demonstration of undone work."  I think Ken was closer to the mark the first time, though I wouldn't say *only* the ScrumMaster should take this responsibility once the team's up and running properly.  Ken's squirrelburger exercise illustrates his true intent.

          I saw a PO learn the hard way to return the entire item to the Product Backlog when it's not actually done.  This causes the team to learn to take on smaller stories and get that last icky 3% actually done.

          --mj

          On Jul 1, 2010, at 10:35 AM, chuckspublicprofile wrote:

           

          The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with "Undone" work.

          http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit

          Does anyone actually use that strategy?

          Outside of release related activities (performance testing, security, stability, etc), does anyone actually split off shippable functionality from a backlog item at the end of the sprint and apportion the estimates to the "done" part and the "undone" part?

          Other than describing release related activities, this last 2.5 paragraphs really bothers me. I try to coach my teams to ALWAYS get to done on a story. I encourage them to not sweep technical debt or bugs or undone work under the rug until later.

          Just curious how anyone else interprets or applies this part of the Scrum Guide.

          Charles Bradley, CSM
          Scrum Coach
          Denver, CO


        • George Dinwiddie
          Hi, Chuck, ... I will sometimes suggest to new scrum teams splitting a story at the end of the sprint, but only along functional story lines--and I recommend
          Message 4 of 5 , Jul 1, 2010
          • 0 Attachment
            Hi, Chuck,

            On 7/1/10 1:35 PM, chuckspublicprofile wrote:
            > The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with "Undone" work.
            >
            > http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
            >
            > Does anyone actually use that strategy?
            >
            > Outside of release related activities (performance testing, security,
            > stability, etc), does anyone actually split off shippable
            > functionality from a backlog item at the end of the sprint and
            > apportion the estimates to the "done" part and the "undone" part?

            I will sometimes suggest to new scrum teams splitting a story at the end
            of the sprint, but only along functional story lines--and I recommend
            that they not make it a regular practice. When I do this, it's because
            they started with a story that was way too big in the first place. I
            coach them to split the stories /before/ the next sprint.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • charles_bradley_scrum_coach
            After re-reading the paragraph above the ones I mentioned, I realize now that the context of this section (Final thoughts) is ONLY in application to orgs who
            Message 5 of 5 , Jul 1, 2010
            • 0 Attachment
              After re-reading the paragraph above the ones I mentioned, I realize now that the context of this section (Final thoughts) is ONLY in application to orgs who are incapable of producing a potentially shippable product increment in one sprint. That makes much more sense now. Ken specifically calls out the case where an org doesn't have the automated testing infrastructure in place yet to fully test an increment within the sprint.

              Ahhh yes... the light bulb comes on.

              Charles Bradley

              --- In scrumdevelopment@yahoogroups.com, "chuckspublicprofile" <chuck-lists2@...> wrote:
              >
              > The last 2.5 paragraphs on the last page of the Scrum Guide talk about dealing with "Undone" work.
              >
              > http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.