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

Re: [scrumdevelopment] What to do when not DONE at the end of a multiple Sprint project

Expand Messages
  • Jussi Mononen
    ... Hi, Do not stretch your current sprint, instead look back and reflect why you did not meet your DoD. Sprintwise you just spill the stories that do not meet
    Message 1 of 13 , May 26, 2010
    • 0 Attachment
      On 05/26/2010 08:12 PM, solutionbuilder wrote:
      >
      > We have project that last anywhere from 2 to 12 sprints. Our teams are
      > small, but consistent throughout the project.
      >
      > At the end of some sprints, since we can not afford automated testing
      > software, we have failure by the domain to test all the features within
      > the sprint (4 weeks) to the point of "total acceptance" aka DoD.
      >
      > In Agile does that mean I really should NOT start the next sprint until
      > that sprint is DoD? This will raise a lot of questions about when the
      > project will finish (limited fixed time funding).

      Hi,

      Do not stretch your current sprint, instead look back and reflect why
      you did not meet your DoD.

      Sprintwise you just spill the stories that do not meet your DoD. They
      usually end up with the highest priority into the next sprints backlog
      unless PO(s) decide to prioritize something above them.

      This might mean that you can not deliver all the features. Communicate
      it as early as possible. Inability to reach DoD means that you are
      trying to do more than you are capable of.

      You probably should commit to a lesser amount of stories for the next
      sprint so that you can implement the test automation. Or, you can ask if
      you could spend one sprint to develop your test automation.

      Also, if you notice that all the stories are 90-95% ready when the
      sprint ends, then your team is most likely cherry picking tasks and the
      "boring"/repetitive stuff is not getting done. In that case you could
      limit work in progress and swarm over the highest priority stories.

      Br,

      --
      - Agile Poodle
      - http://www.jussimononen.info/
      - http://www.twitter.com/agilepoodle
    • Victor Hugo de Oliveira
      A Sprint is a box of time to facilitate focus. A Sprint ends when the time ends. The limited funding in an Agile perspective is not about delivering all the
      Message 2 of 13 , May 26, 2010
      • 0 Attachment
        A Sprint is a box of time to facilitate focus. A Sprint ends when the time ends.

        The limited funding in an Agile perspective is not about delivering all the features, is about achieving the projects goal.

        Also, you should aim to deliver 100% whatever you start building, and not 90% of a lot of things. Try to keep that in mind on the planning.
        Whatever is considered not done is included in the next Sprint, but focus on the goal of the project.

        Hope it helps you.
        Best Regards,
        Victor

        On Wed, May 26, 2010 at 2:12 PM, solutionbuilder <greg_della-croce@...> wrote:
         

        We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.

        At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.

        In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).

        Any experiences to share?




        --
        Victor Hugo de Oliveira

        Scrum & Agile Blog
        http://csvo.wordpress.com

        Concrete Solutions
        new edition: http://www.concretesolutions.com.br/index_eng/

        +55 21 2240 2030
        +55 11 4119 0449
        R. São José 90, 2121
        20010-020
        Rio de Janeiro, RJ, Brasil
      • Bachan Anand
        Hi Greg, Just wondering whether acceptance testing was part of the DoD and if so what is the feedback from the team on why the team is not able to meet the
        Message 3 of 13 , May 26, 2010
        • 0 Attachment
          Hi Greg,
          Just wondering whether acceptance testing was  part of the DoD  and if so what is the  feedback from the team on why the team is not able to meet the commitment, it would be great to listen to the team and get their feedback.

          If there is consistency in testing not being completed as part of the Sprint , it happens mostly because of a lack of belief in the team that testing can be completed and there is not enough time spent to look at new ways to achieve this goal ( if that indeed is a goal the team agreed upon)


          Bachan Anand
          WORK is GOOD
          Tel  +1-949-232-8900
          Contact Me LinkedinFacebookFacebookTwitter


          On Wed, May 26, 2010 at 10:12 AM, solutionbuilder <greg_della-croce@...> wrote:
           

          We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.

          At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.

          In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).

          Any experiences to share?


        • Angel Java Lopez
          Hi people! In my experience, the Product Owner decide if the not-done feature is included or not in the next sprint. One case: in a fixed time project, we
          Message 4 of 13 , May 26, 2010
          • 0 Attachment
            Hi people!

            In my experience, the Product Owner decide if the "not-done" feature is included or not in the next sprint.

            One case: in a fixed time project, we "mis-evaluated" the cost of implementing a feature. And the start of the next sprint, the PO decided to forget that feature, it was more important for him to continue with the next story. And the current story, without that feature, was acceptable to him.

            In another case: a similar situation, the PO decided: We need that feature, and put it in high priority. And it was implemented/completed in the next sprint.

            Angel "Java" Lopez
            http://www.ajlopez.com
            http://twitter.com/ajlopez


            On Wed, May 26, 2010 at 2:12 PM, solutionbuilder <greg_della-croce@...> wrote:
             

            We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.

            At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.

            In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).

            Any experiences to share?


          • woynam
            I m curious. What do you mean that you can t afford automated testing? There are plenty of free automated testing tools out there, e.g. FitNesse, WebDriver. If
            Message 5 of 13 , May 26, 2010
            • 0 Attachment
              I'm curious. What do you mean that you can't afford automated testing? There are plenty of free automated testing tools out there, e.g. FitNesse, WebDriver.

              If it's a staffing issue, then you've discovered that quality is free. Discovering defects late in the game will actually slow your ability to deliver value, so having the team write automated tests early actually saves money in the long run.

              Mark


              --- In scrumdevelopment@yahoogroups.com, "solutionbuilder" <greg_della-croce@...> wrote:
              >
              > We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.
              >
              > At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.
              >
              > In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).
              >
              > Any experiences to share?
              >
            • Adam Sroka
              Totally! That s also why we coach teams not to start stories they can t finish in the Sprint. If you don t start it then the PO is free to change priorities
              Message 6 of 13 , May 26, 2010
              • 0 Attachment
                Totally! That's also why we coach teams not to start stories they can't finish in the Sprint. If you don't start it then the PO is free to change priorities without throwing away work.

                Of course, sometimes you start something thinking you can finish but find out that it is more work than you anticipated. In that case it is the PO's prerogative to say whether you continue or throw it away and do something else.

                On Wed, May 26, 2010 at 1:17 PM, Angel Java Lopez <ajlopez2000@...> wrote:
                 

                Hi people!

                In my experience, the Product Owner decide if the "not-done" feature is included or not in the next sprint.

                One case: in a fixed time project, we "mis-evaluated" the cost of implementing a feature. And the start of the next sprint, the PO decided to forget that feature, it was more important for him to continue with the next story. And the current story, without that feature, was acceptable to him.

                In another case: a similar situation, the PO decided: We need that feature, and put it in high priority. And it was implemented/completed in the next sprint.

                Angel "Java" Lopez
                http://www.ajlopez.com
                http://twitter.com/ajlopez




                On Wed, May 26, 2010 at 2:12 PM, solutionbuilder <greg_della-croce@...> wrote:
                 

                We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.

                At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.

                In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).

                Any experiences to share?



              • Roy Morien
                First, shorten your sprint from 4 weeks to 2 weeks. Second, stick to the timebox of 2 weeks ... when the sprint ends, stop doing it!. Third ... ask yourself,
                Message 7 of 13 , May 26, 2010
                • 0 Attachment
                  First, shorten your sprint from 4 weeks to 2 weeks.
                   
                  Second, stick to the timebox of 2 weeks ... when the sprint ends, stop doing it!.
                   
                  Third ... ask yourself, is 100% of 90% better than 90% of 100%? There is nothing sacred or unchangeable about your sprint plan; the part of the plan that says you will do this list of things. That is necessarilly uncertain, and must be seen as an intention, not a rock hard commitment.
                   
                  Did you see the movie Titanic? Well, apart from the love story nonsense, it was essentially historically true. The Captain of the Titanic had a plan to arrive in New York at a certain time, to beat the trans-Atlantic speed record. He refused to change his plan, even in the face of some serious risks. His plan was not adaptive, and it ended in the greatest maritime disaster of all time.
                   
                  I also like the fact that they found the wreck of the Titanic by following what they call the 'debris field' which is where they find all the bits and pieces that fell off the ship as it was sinking. I liken many software development projects to this situation ... the 'debris field' is all of those almost finished, not quite tested software components that can point us to the wreck of the system.
                   
                  Maybe I am being a little bit fanciful here, but I like the analogy myself.
                   
                  Regards,
                  Roy Morien
                   

                  To: scrumdevelopment@yahoogroups.com
                  From: greg_della-croce@...
                  Date: Wed, 26 May 2010 17:12:18 +0000
                  Subject: [scrumdevelopment] What to do when not DONE at the end of a multiple Sprint project

                   
                  We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.

                  At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.

                  In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).

                  Any experiences to share?




                  Find it on Domain.com.au Need a new place to live?
                • George Dinwiddie
                  ... I do, too, Roy. It s a good one. - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
                  Message 8 of 13 , May 26, 2010
                  • 0 Attachment
                    Roy Morien wrote:
                    > Maybe I am being a little bit fanciful here, but I like the analogy myself.

                    I do, too, Roy. It's a good one.

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Maurice le Rutte
                    Roy Morien schreef:   First, shorten your sprint from 4 weeks to 2 weeks.   Second, stick to the timebox of 2 weeks ... when the sprint ends, stop doing it!.
                    Message 9 of 13 , May 27, 2010
                    • 0 Attachment
                      Roy Morien schreef:
                       

                      First, shorten your sprint from 4 weeks to 2 weeks.
                       
                      Second, stick to the timebox of 2 weeks ... when the sprint ends, stop doing it!.
                       
                      Third ... ask yourself, is 100% of 90% better than 90% of 100%? There is nothing sacred or unchangeable about your sprint plan; the part of the plan that says you will do this list of things. That is necessarilly uncertain, and must be seen as an intention, not a rock hard commitment.
                       

                      I don't know about shortening the timebox to 2 weeks, that is not the problem and doesn't cause it. And personally, I prefer 4 week timeboxes because of the creational rythm it provides. For those who can read Dutch or are willing to withstand an automated translation see http://www.scrummaster.nl/2009/11/16/moeten-we-de-lengte-van-onze-sprint-groter-maken/.

                      You should track progress within your sprint. For example with the sprint burndown graph or by simply watching the amount of sticky notes decreasing. When anyone in the Team (SM, PO, Dev) starts to get the itchy feeling that you may have taken on too much it is time to adapt. For example by decreasing the scope of the remaining backlog items. It is also the POs responsibility to make sure the Sprint goal is met and he should be willing to accept that the ideas in the beginning of the sprint might not feasible. Of course, there is a bottom limit and if that is hit you might decide which items to drop. Anyway, decrease the amount of work you take on for next sprint.

                      Maurice.

                      -- 
                      http://www.scrummaster.nl / http://twitter.com/scrumnl
                    • JackM
                      What you need to do is end the sprint. Re-prioritize any unfinished work along with any new hi priority items into the next sprint. Perhaps adjust the number
                      Message 10 of 13 , May 27, 2010
                      • 0 Attachment
                        What you need to do is end the sprint. Re-prioritize any unfinished work along with any new hi priority items into the next sprint. Perhaps adjust the number of stories accepted into the new sprint so that you can finish next time.

                        Never extend the sprint to finish unfinished work.

                        Hope this helps you

                        Jack
                        www.agilebuddy.com
                        twitter.com/agilebuddy
                        blog.agilebuddy.com

                        --- In scrumdevelopment@yahoogroups.com, "solutionbuilder" <greg_della-croce@...> wrote:
                        >
                        > We have project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.
                        >
                        > At the end of some sprints, since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.
                        >
                        > In Agile does that mean I really should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).
                        >
                        > Any experiences to share?
                        >
                      • Roy Morien
                        Well, whether 2 week or 4 week sprints is preferable I think is arguable, and a matter of opinion, and I guess experience. But I DO think that in the situation
                        Message 11 of 13 , May 27, 2010
                        • 0 Attachment
                          Well, whether 2 week or 4 week sprints is preferable I think is arguable, and a matter of opinion, and I guess experience. But I DO think that in the situation decribed, the 4 week sprint IS part of the problem, and a 2 week sprint would assit in solving the problem. It is a shorter time horizon, therefore easier to plan with a bit more certainty, it gives more frequent opportunities for demonstration of progress. ALthough I have no stats to support this, I would suggest that this shorter period makes for a more controlled sprint, less unfinished work, more accurate estimates of achievement in the sprint, a greater sense of urgencyand commitment, and overall a better psychology and focus in the team environment.
                           
                          I certainly think it would reduce the occurence of that 'itchy feeling' that you mention, and the amount of scope of the backlog items that need to be reduced.
                           
                          But, yeah, just sayin'.
                           
                          Regards,
                          Roy Morien
                           

                          To: scrumdevelopment@yahoogroups.com
                          From: maurice.lerutte@...
                          Date: Thu, 27 May 2010 18:13:01 +0200
                          Subject: Re: [scrumdevelopment] What to do when not DONE at the end of a multiple Sprint project

                           
                          Roy Morien schreef:
                           

                          First, shorten your sprint from 4 weeks to 2 weeks.
                           
                          Second, stick to the timebox of 2 weeks ... when the sprint ends, stop doing it!.
                           
                          Third ... ask yourself, is 100% of 90% better than 90% of 100%? There is nothing sacred or unchangeable about your sprint plan; the part of the plan that says you will do this list of things. That is necessarilly uncertain, and must be seen as an intention, not a rock hard commitment.
                           

                          I don't know about shortening the timebox to 2 weeks, that is not the problem and doesn't cause it. And personally, I prefer 4 week timeboxes because of the creational rythm it provides. For those who can read Dutch or are willing to withstand an automated translation see http://www.scrummas ter.nl/2009/ 11/16/moeten- we-de-lengte- van-onze- sprint-groter- maken/.

                          You should track progress within your sprint. For example with the sprint burndown graph or by simply watching the amount of sticky notes decreasing. When anyone in the Team (SM, PO, Dev) starts to get the itchy feeling that you may have taken on too much it is time to adapt. For example by decreasing the scope of the remaining backlog items. It is also the POs responsibility to make sure the Sprint goal is met and he should be willing to accept that the ideas in the beginning of the sprint might not feasible. Of course, there is a bottom limit and if that is hit you might decide which items to drop. Anyway, decrease the amount of work you take on for next sprint.

                          Maurice.

                          -- 
                          http://www.scrummas ter.nl / http://twitter. com/scrumnl



                          Australia's #1 job site If It Exists, You'll Find it on SEEK
                        • Steve Ropa
                          This is good advice. I would also recommend you shorten your sprints dramatically. I m also a little concerned that perhaps you are still waiting till all
                          Message 12 of 13 , May 28, 2010
                          • 0 Attachment
                            This is good advice.  I would also recommend you shorten your sprints dramatically.  I'm also a little concerned that perhaps you are still waiting till "all the coding is done" to engage the testing contingent.  Shortening your sprint might help you to move away from that.  I personally like one or two week sprints.
                             
                            Steve

                            From: JackM
                            Sent: Thursday, May 27, 2010 3:38 PM
                            Subject: [scrumdevelopment] Re: What to do when not DONE at the end of a multiple Sprint project

                             

                            What you need to do is end the sprint. Re-prioritize any unfinished work along with any new hi priority items into the next sprint. Perhaps adjust the number of stories accepted into the new sprint so that you can finish next time.

                            Never extend the sprint to finish unfinished work.

                            Hope this helps you

                            Jack
                            www.agilebuddy.com
                            twitter.com/agilebuddy
                            blog.agilebuddy.com

                            --- In scrumdevelopment@yahoogroups.com, "solutionbuilder" <greg_della-croce@...> wrote:

                            >
                            > We have
                            project that last anywhere from 2 to 12 sprints. Our teams are small, but consistent throughout the project.
                            >
                            > At the end of some sprints,
                            since we can not afford automated testing software, we have failure by the domain to test all the features within the sprint (4 weeks) to the point of "total acceptance" aka DoD.
                            >
                            > In Agile does that mean I really
                            should NOT start the next sprint until that sprint is DoD? This will raise a lot of questions about when the project will finish (limited fixed time funding).
                            >
                            > Any experiences to share?
                            >

                          Your message has been successfully submitted and would be delivered to recipients shortly.