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

Neverending Stories

Expand Messages
  • Michael Wollin
    We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that
    Message 1 of 17 , Dec 2, 2011
    • 0 Attachment
      We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.

      Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.

      I presume this is a tracking tool driven "need."

      Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?

      Thanks.

      Michael
    • Wouter Lagerweij
      Triage would be more along the lines of backlog grooming (estimating, detailing en prioritising the work). A Scrum team would do that work (5-10% of sprint
      Message 2 of 17 , Dec 2, 2011
      • 0 Attachment
        Triage would be more along the lines of backlog grooming (estimating, detailing en prioritising the work). A Scrum team would do that work (5-10% of sprint time, I think the normal time for that is), but not plan it in as a story.

        Adding tasks to an issue tracking system during the sprint is fine, of course. Deciding priority (do now, or not) should be done immediately. If the team feels more comfortable to group all those items that are new and need to be picked up right now under one name, that is also fine. I'd probable call it 'unplanned', or 'production issues', though. Triage indicates another type of work. 

        I would be curious to know *why* they feel they need to track this work in this way. Is the triaging taking so much time? Are they expected to account for every minute spent in the bug tracker?

        Wouter

        On Fri, Dec 2, 2011 at 5:25 PM, Michael Wollin <yahoo@...> wrote:
         

        We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.

        Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.

        I presume this is a tracking tool driven "need."

        Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?

        Thanks.

        Michael




        --
        Wouter Lagerweij         | wouter@...
      • ag12340@rocketmail.com
        Why are you uncomfortable with it? ... They are grouping issues under a story because they need a grouping and the way tool is. Not everything in backlog has
        Message 3 of 17 , Dec 2, 2011
        • 0 Attachment
          Why are you uncomfortable with it?

          >> I presume this is a tracking tool driven "need."
          They are grouping issues under a "story" because they need a grouping and the way tool is. Not everything in backlog has to be a story.

          Are you uncomfortable with the grouping or that tool calls it a story?


          --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
          >
          > We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.
          >
          > Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.
          >
          > I presume this is a tracking tool driven "need."
          >
          > Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?
          >
          > Thanks.
          >
          > Michael
          >
        • Michael Wollin
          I guess I can give that up. It s a zero point story anyway. I just thought it violated the semantics of user story. However, it IS a convenient way to track
          Message 4 of 17 , Dec 2, 2011
          • 0 Attachment
            I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does. 

            On Dec 2, 2011, at 1:26 PM, ag12340@... wrote:

             

            Why are you uncomfortable with it?

            >> I presume this is a tracking tool driven "need."
            They are grouping issues under a "story" because they need a grouping and the way tool is. Not everything in backlog has to be a story.

            Are you uncomfortable with the grouping or that tool calls it a story?

            --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
            >
            > We rotate one of our development teams to do support for a period of months. Their work is partly planned, and partly reactive. We have a triage process that looks at incoming issues. We fix critical issues immediately and otherwise create a story for the backlog for the issue. That story will be pointed by the team and prioritized by the customer.
            >
            > Our PO team created a "story" called "Triage." They use it in Mingle to keep track of emerging support tasks. I am uncomfortable with this and I am looking for help making the case that this is not what we really want to be doing. The Triage story ends at the end of the sprint, i.e., the story would be Sprint 109 Triage.
            >
            > I presume this is a tracking tool driven "need."
            >
            > Do you agree with me that this is not best practice and it is a perversion of the notion of a story? How can I persuade the POs to use another approach? Am I missing something?
            >
            > Thanks.
            >
            > Michael
            >


          • Michael James
            ... Triage doesn t sound much like a user story to me either, but there s never been a rule in Scrum that all PBIs have to be user stories. Since no one likes
            Message 5 of 17 , Dec 2, 2011
            • 0 Attachment
              On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:

              > I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.

              Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.

              Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?

              --mj
            • Michael Wollin
              Rome wasn t built in a day. :) It s progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams
              Message 6 of 17 , Dec 3, 2011
              • 0 Attachment
                Rome wasn't built in a day. :)

                It's progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams for new product development.

                These systems are tricky, a complex Rube Goldberg integration of home grown and external vendor products. Bleeding edge technology, completely integrated global file-based video workflow (satellite, FTP, distributed metadata, editing growing HD video files. etc., and a 30 petabyte digital library). It's another interesting and non-trivial discussion as to how much constitutes overbuilding (vs Lean) belts and braces around these systems. For example, with a video render farm we are using, the servers will choke occasionally on some kinds of video and it's up to us to figure out why, under the pressure sometimes of a breaking news event. I feel sorry for those of you working on yet another ERP or e-commerce web site. :)

                On Dec 2, 2011, at 9:41 PM, Michael James wrote:

                > On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:
                >
                >> I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.
                >
                > Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.
                >
                > Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?
                >
                > --mj
                >
                >
                >
                > ------------------------------------
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                >
                >
                >
                > /docs.yahoo.com/info/terms/
                >
              • mcleaper
                I never liked having these kinds of activities as stories and it is my belief that they are hold overs from the command and control way of thinking (everything
                Message 7 of 17 , Dec 4, 2011
                • 0 Attachment
                  I never liked having these kinds of activities as stories and it is my belief that they are hold overs from the command and control way of thinking (everything the team does must be planned and recorded and it must add up to at least 40 hours per week per person or they will goof off). The PBI was not meant to be used as a time tracker but if the team is comfortable with it and adding that story helps them estimate how many other stories they can handle during the sprint then I would let it be.

                  -M

                  --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
                  >
                  > Rome wasn't built in a day. :)
                  >
                  > It's progress to have only one of our teams on full time support (they all rotate on and off over time), freeing the other teams for new product development.
                  >
                  > These systems are tricky, a complex Rube Goldberg integration of home grown and external vendor products. Bleeding edge technology, completely integrated global file-based video workflow (satellite, FTP, distributed metadata, editing growing HD video files. etc., and a 30 petabyte digital library). It's another interesting and non-trivial discussion as to how much constitutes overbuilding (vs Lean) belts and braces around these systems. For example, with a video render farm we are using, the servers will choke occasionally on some kinds of video and it's up to us to figure out why, under the pressure sometimes of a breaking news event. I feel sorry for those of you working on yet another ERP or e-commerce web site. :)
                  >
                  > On Dec 2, 2011, at 9:41 PM, Michael James wrote:
                  >
                  > > On Dec 2, 2011, at 10:31 AM, Michael Wollin wrote:
                  > >
                  > >> I guess I can give that up. It's a zero point story anyway. I just thought it violated the semantics of "user story." However, it IS a convenient way to track emergent work, which is a third to half of what this team does.
                  > >
                  > > Triage doesn't sound much like a user story to me either, but there's never been a rule in Scrum that all PBIs have to be user stories.
                  > >
                  > > Since no one likes fixing operational issues all the time, and interruptions impede your product development, I suppose your longer term goal is to address the quality issues that are probably causing them?
                  > >
                  > > --mj
                  > >
                  > >
                  > >
                  > > ------------------------------------
                  > >
                  > > To Post a message, send it to: scrumdevelopment@...
                  > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                  > >
                  > >
                  > >
                  > > /docs.yahoo.com/info/terms/
                  > >
                  >
                • Dominick Deinde
                  Do we generate design documents in scrum and when ?
                  Message 8 of 17 , Feb 1, 2012
                  • 0 Attachment

                    Do we generate design documents in scrum and when ?

                     

                  • Chet Hendrickson
                    Hello Dominick, Scrum is silent on this point. The development team my use process they like, as long as they meet the agreed upon definition of done.
                    Message 9 of 17 , Feb 1, 2012
                    • 0 Attachment
                      Re: [scrumdevelopment] Design documents Hello Dominick,

                      Scrum is silent on this point.  The development team my use process they like, as long as they meet the agreed upon definition of done. However, I would suggest you take a quick look a the Agile Manifesto for some additional guidance.

                      chet 



                      Wednesday, February 1, 2012, 11:41:44 AM, you wrote:


                        
                      Do we generate design documents in scrum and when ?
                       




                      -- 
                      Best regards,
                       Chet Hendrickson                          
                      mailto:lists@...
                       Check out our upcoming CSM Plus courses @
                      http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
                    • Joshua Partogi
                      Yes. Within every Sprint. On Wednesday, February 1, 2012, Dominick Deinde ... -- @jpartogi
                      Message 10 of 17 , Feb 1, 2012
                      • 0 Attachment
                        Yes. Within every Sprint.

                        On Wednesday, February 1, 2012, Dominick Deinde <dominick@...> wrote:
                        >  
                        >
                        > Do we generate design documents in scrum and when ?
                        >
                        >  
                        >
                        >

                        --
                        @jpartogi
                      • George Dinwiddie
                        Dominick, ... Do you need design documents? Who will read them, and when? - George -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                        Message 11 of 17 , Feb 1, 2012
                        • 0 Attachment
                          Dominick,

                          On 2/1/12 11:41 AM, Dominick Deinde wrote:
                          >
                          >
                          > Do we generate design documents in scrum and when ?

                          Do you need design documents? Who will read them, and when?

                          - George

                          --
                          ----------------------------------------------------------------------
                          * George Dinwiddie * http://blog.gdinwiddie.com
                          Software Development http://www.idiacomputing.com
                          Consultant and Coach http://www.agilemaryland.org
                          ----------------------------------------------------------------------
                        • Dominick Deinde
                          We have design documents as deliverables for the software development process now. My client will like to keep them as part of scrum when we convert. According
                          Message 12 of 17 , Feb 1, 2012
                          • 0 Attachment
                            We have design documents as deliverables for the software development
                            process now. My client will like to keep them as part of scrum when we
                            convert. According to some of my research, we can do high level design such
                            as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                            for detailed design. What do you think ?

                            -----Original Message-----
                            From: scrumdevelopment@yahoogroups.com
                            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                            Sent: Wednesday, February 01, 2012 6:11 PM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Design documents

                            Dominick,

                            On 2/1/12 11:41 AM, Dominick Deinde wrote:
                            >
                            >
                            > Do we generate design documents in scrum and when ?

                            Do you need design documents? Who will read them, and when?

                            - George

                            --
                            ----------------------------------------------------------------------
                            * George Dinwiddie * http://blog.gdinwiddie.com
                            Software Development http://www.idiacomputing.com
                            Consultant and Coach http://www.agilemaryland.org
                            ----------------------------------------------------------------------



                            ------------------------------------

                            To Post a message, send it to: scrumdevelopment@...
                            To Unsubscribe, send a blank message to:
                            scrumdevelopment-unsubscribe@...! Groups Links
                          • Gary Brown
                            Hello, Dominick! ... Here is what I do. If a project is guess-timated to take three months, I take about a week to establish team working agreements (you can
                            Message 13 of 17 , Feb 1, 2012
                            • 0 Attachment
                              Hello, Dominick!

                              Quoting Dominick Deinde <dominick@...>:

                              > We have design documents as deliverables for the software development
                              > process now. My client will like to keep them as part of scrum when we
                              > convert. According to some of my research, we can do high level design such
                              > as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                              > for detailed design. What do you think ?

                              Here is what I do. If a project is guess-timated to take three
                              months, I take about a week to establish team working agreements (you
                              can omit or reduce this for mature Agile teams), about a week to
                              understand the requirements and learn about things we don't know, and
                              about a week to establish the high level system design. I call that
                              HLD the essential abstraction. What I mean by that is here are the
                              set of components we need, and here are the things they need to do.
                              Don't get stuck on tools or techniques, just focus on WHAT needs to be
                              done. Draw the picture, call it done.

                              Build the system story by story, doing the simplest thing that could
                              possibly work. That means, building exactly what is needed for now,
                              contains no duplication, passes all of the tests, and clearly reveals
                              its intent. Nothing more, nothing less.

                              As you pick up each new story, ask what do we need to do to make this
                              fit easily into the design. Refactor first, then add the new design
                              element. Do this every time, and you can hold entropy at arms length
                              indefinitely.

                              GB.



                              ----------------------------------------------------------------
                              This message was sent using IMP, the Internet Messaging Program.
                            • JackM
                              Yes most definitely if you need it. If you don t then don t do it. Always think about who is consuming this document. Will you be able to keep it up-to-date.
                              Message 14 of 17 , Feb 1, 2012
                              • 0 Attachment
                                Yes most definitely if you need it. If you don't then don't do it.

                                Always think about who is consuming this document. Will you be able to keep it up-to-date. Most documents are out of date from the moment the pen goes down. But there are many cases where documents are needed and those should be delivered just like other aspects of software development is delivered. Create a task for it, make it part of the acceptance test criteria for the story etc.

                                Hope this helps
                                Jack
                                www.agilebuddy.com

                                --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@...> wrote:
                                >
                                > Do we generate design documents in scrum and when ?
                                >
                              • Kurt Häusler
                                I am a fan of generating requirements documentation in the form of executable acceptance tests, specifications in the form of unit tests, and a detailed design
                                Message 15 of 17 , Feb 1, 2012
                                • 0 Attachment
                                  I am a fan of generating requirements documentation in the form of executable acceptance tests, specifications in the form of unit tests, and a detailed design of the software in the form of compilable or runnable source code.


                                  On Feb 1, 2012, at 5:41 PM, Dominick Deinde wrote:

                                  >
                                  > Do we generate design documents in scrum and when ?
                                • George Dinwiddie
                                  Dominick, ... Consider the documents the same as you do code, then. I wouldn t spend too much effort on them along the way, as the design of the code is likely
                                  Message 16 of 17 , Feb 1, 2012
                                  • 0 Attachment
                                    Dominick,

                                    On 2/1/12 8:29 PM, Dominick Deinde wrote:
                                    > We have design documents as deliverables for the software development
                                    > process now. My client will like to keep them as part of scrum when we
                                    > convert. According to some of my research, we can do high level design such
                                    > as architecture at sprint 0. Then spend 4 hrs discussion during each sprint
                                    > for detailed design. What do you think ?

                                    Consider the documents the same as you do code, then. I wouldn't spend
                                    too much effort on them along the way, as the design of the code is
                                    likely to change if you're doing increment design. But keep enough
                                    information that you feel confident you can write the necessary
                                    documents at the end, of the "as built" system.

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  • ashish_wrt
                                    I tried Scrum both ways with and without design upfront and now I do Scrum only with design upfront (usually light) and a design review before coding starts
                                    Message 17 of 17 , Feb 2, 2012
                                    • 0 Attachment
                                      I tried Scrum both ways with and without design upfront and now I do Scrum only with design upfront (usually light) and a design review before coding starts for anything not very simple. Sometimes I go for comprehensive and detailed design.

                                      In most cases design document is only a wiki page with two diagrams or something the developer explains on board on how they plan to do it and we take a pic and put it on our wiki with additional notes by the developer.

                                      It is part of the sprint and usually before the developer starts coding.

                                      During coding developer is free to deviate from his original design and regroup with team to discuss and communicate his changes.

                                      Value is in thinking through and getting input.

                                      Ashish
                                      http://www.agilewrap.com


                                      --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@...> wrote:
                                      >
                                      > Do we generate design documents in scrum and when ?
                                      >
                                    Your message has been successfully submitted and would be delivered to recipients shortly.