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

view/track the features developed (and their impact) before the demo

Expand Messages
  • momofromthablock
    Hey folks - I m working with a team where there s a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the
    Message 1 of 11 , Jul 5, 2012
    • 0 Attachment
      Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.

      This leads to long and tensioned demoes and also to additional development after the demo.

      Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?

      It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)

      Any other tips or ideas on this?

      Thanks
      Andrei
    • Jesse Houwing
      Hey Andrei, By calling it The Demo , it sounds like this is taking place at the Sprint Review meeting, and we recently had a discussion about that meeting
      Message 2 of 11 , Jul 5, 2012
      • 0 Attachment
        Hey Andrei,

        By calling it "The Demo", it sounds like this is taking place at the Sprint Review meeting, and we recently had a discussion about that meeting that basically comes down to: During that meeting you should not expect any surprises.

        Make sure you involve your stakeholders/productowner during the sprint and show the features (and if possible get preliminary approval) while the sprint is in progress. That way, once the Sprint Review commences, you'll have a lot of people that know exactly what to expect.

        Make sure you capture the tendencies of your customer and make it part of your peer reviews and let your team include these kinds of things in test/qa during the sprint.

        Another thing to make sure is that if these things are hard to pin down, either try to get these people better involved in the Backlog grooming sessions, do a little more story boarding, do a few mockups, try to elicit these hard to pin down things and pin them down. Alternatively, explain that you're following a process that is empirical, ask them to approve what is there if it covers their needs and stick a new PBI on the backlog that contains their additional wishes. That is, as long as they're not finding a lot things that should be considered bugs.

        Does that help?

        On Thu, Jul 5, 2012 at 11:48 AM, momofromthablock <andrei.berechet@...> wrote:
        Hey folks - I'm working with a team where there's a lot of back and forth during the demo re:  how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.

        This leads to long and tensioned demoes and also to additional development after the demo.

        Any idea how to circumvent this? Specifically do you have any tips on catching these things  before the demo?

        It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)

        Any other tips or ideas on this?

        Thanks
        Andrei



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

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

        <*> To change settings via email:
            scrumdevelopment-digest@yahoogroups.com
            scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/


      • RonJeffries
        Hi ... ... I suggest following this convention: If it wasn t expressed at the beginning of the Sprint, then it wasn t part of the story. Want something
        Message 3 of 11 , Jul 5, 2012
        • 0 Attachment
          Hi ...

          On Jul 5, 2012, at 5:48 AM, momofromthablock wrote:

          Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself. 

          This leads to long and tensioned demoes and also to additional development after the demo.

          Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?

          It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :) 

          I suggest following this convention: If it wasn't expressed at the beginning of the Sprint, then it wasn't part of the story. Want something different now? Fine, provide a new story for next Sprint.

          Ron Jeffries
          www.XProgramming.com
          Sometimes I give myself admirable advice, but I am incapable of taking it.
          -- Mary Wortley Montagu



        • Erick Sasse
          One thing that could help is having the PO give constant feedback during the sprint.
          Message 4 of 11 , Jul 5, 2012
          • 0 Attachment
            One thing that could help is having the PO give constant feedback
            during the sprint.

            Em 05/07/2012, às 06:48, momofromthablock <andrei.berechet@...> escreveu:

            > Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.
            >
            > This leads to long and tensioned demoes and also to additional development after the demo.
            >
            > Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?
            >
            > It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)
            >
            > Any other tips or ideas on this?
            >
            > Thanks
            > Andrei
            >
            >
            >
            > ------------------------------------
            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
            >
            >
            >
          • nkhanna2006
            Hi Andrei, Sometimes, our team doesn t wait till the end of the Sprint to have a demo. for select Stories. Completed Stories, if ready for demonstration, are
            Message 5 of 11 , Jul 5, 2012
            • 0 Attachment
              Hi Andrei,

              Sometimes, our team doesn't wait till the end of the Sprint to have a demo. for select Stories.

              Completed Stories, if ready for demonstration, are reviewed with the Product Owner and the stakeholders, depending on availability.
              (Caution - we don't want to take much time away from the Dev Team)

              This has worked for us as the Stories are small and we can clearly state what we are demonstrating, and what is forthcoming.

              Anything new is captured as new Stories.

              There is still a demonstration at the end, where any remaining Stories are discussed.

              I don't know if anyone else has experienced such a scenario, but this has worked well for us.

              Regards,
              Nitin.


              --- In scrumdevelopment@yahoogroups.com, "momofromthablock" <andrei.berechet@...> wrote:
              >
              > Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.
              >
              > This leads to long and tensioned demoes and also to additional development after the demo.
              >
              > Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?
              >
              > It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)
              >
              > Any other tips or ideas on this?
              >
              > Thanks
              > Andrei
              >
            • Javier Morales
              Hello... I am the PO for has a lot of nuanced functionality. I have been dealing with this sort of thing for some time. When it comes to requirements, I start
              Message 6 of 11 , Jul 5, 2012
              • 0 Attachment
                Hello...

                I am the PO for has a lot of nuanced functionality. 

                I have been dealing with this sort of thing for some time. 

                When it comes to requirements, I start with a conversation with the scrum master (who also has responsibility for system engineering - I know that's not by the book but no point in beating your head against a wall that will not move) to explain how the functionality should work (to the extend that I think makes sense). This conversation covers both the immediate use of the functionality and also how this functionality fits into a longer term picture (things that I want to enable or potentially enable by building on the immediate functionality). 

                Side note, I get pulled into customer engagements on a regular basis. I often BCC the scrum master on these discussions (with commentary I add). This has been extremely helpful in getting him to understand the nuanced behavior that's required in our product.

                In any case, the scrum master in turn lets me know about considerations on his end that may impact the level of effort to deliver the functionality. If the last 10% of functionality is going to represent 40% of the cost then I go back and ask myself whether I really want that last 10% or whether we can simplify or change requirements to lower the cost of implementation.

                Often this can be an extended period of discussion as the scrum master will bring in individual developers into these conversations.

                So... 
                • in a conversation, make sure the scrum master / system engineer understands the requirements and that I answer all of his questions about how to implement
                • provide the scrum master / system engineer and developers perspective on why I want the functionality and what people will do with the functionality
                • the scrum master / system engineer and developer provides perspective on the cost (both current and future if we substantially add to the baseline cost to sustain the product) and implications of the requirements and potentially alleviation to cost / complexity

                The end of this is a verbal agreement about the required functionality and the salient things that should be documented.
                I write that down and ask the developer to review it and let me know if we miscommunicated in some way. (I would like to co-edit these with the developers but I have not gotten them there yet).

                These are the requirements that come to the planning meeting. There're no grooming sessions for the backlog as much as ongoing collaboration to make sure everyone understand what we are trying to implement.

                If additional questions come up during development the developer will approach me for clarification. This is their judgement call - but if they make too many assumptions they will be redoing some of their work. I don't ever give them a hard time for rework but I do try to get more complete requirements next go around if too many questions come up. The requirements, after all, are my responsibility. 

                Usually the clarifications do not substantially impact the scope of the request. However, if that's not the case then we do a couple of things:
                • trade something else off so that I get the functionality I want
                • agree on a subset for the current iteration (in some cases this may be even less than the initial request) and then queue up the rest for the next iteration.

                If something does not match my expectations I then usually take a hard look at my expectations and ask myself whether it is worth redoing (and frustrating the development team). In most cases, it is not. However, if I do ask that something be redone I usually go overboard in explaining the reason...

                One other thing: People do not like to redo things so they start calling / IMing / emailing out of their own volition if the requirements were not sufficiently clear. That in turn gives me an opportunity to instill the overall philosophy guiding implementation which helps developers implement closer to my expectations. Over time this has resulted in a nice positive feedback loop.

                I took over as PO a couple of years ago when the developers had a major release that was almost content-free. Everyone blamed development which, of course, is ludricous.
                In the last iteration the same team delivered more content in two weeks than they delivered for that major release. In the last 12 months they have delivered more content than they had delivered in the last 4 years.

                From my perspective I would say that the "long tensioned demoes" are really the problem.
                If you missed it then you missed it. No big deal. Just add it to the next iteration and work with the team on requirements clarification.

                Jav

                On Jul 5, 2012, at 6:36 AM, RonJeffries wrote:

                 

                Hi ...


                On Jul 5, 2012, at 5:48 AM, momofromthablock wrote:

                Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself. 

                This leads to long and tensioned demoes and also to additional development after the demo.

                Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?

                It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :) 

                I suggest following this convention: If it wasn't expressed at the beginning of the Sprint, then it wasn't part of the story. Want something different now? Fine, provide a new story for next Sprint.

                Ron Jeffries
                www.XProgramming.com
                Sometimes I give myself admirable advice, but I am incapable of taking it.
                -- Mary Wortley Montagu





              • Steve
                Andrei Are representatives of the review questioners involved in the low-level detail specification that seems to be causing your problems actually
                Message 7 of 11 , Jul 6, 2012
                • 0 Attachment
                  Andrei

                  Are 'representatives' of the review 'questioners' involved in the low-level detail specification that seems to be causing your problems actually involved during the Sprint? They should be!

                  One technique that I use is to get one of the business people who were involved during the Sprint to do the demo.

                  Hope that helps

                  Steve

                  --- In scrumdevelopment@yahoogroups.com, "momofromthablock" <andrei.berechet@...> wrote:
                  >
                  > Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.
                  >
                  > This leads to long and tensioned demoes and also to additional development after the demo.
                  >
                  > Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?
                  >
                  > It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)
                  >
                  > Any other tips or ideas on this?
                  >
                  > Thanks
                  > Andrei
                  >
                • frede_swe
                  Andrei, Could it be a lack of communication between the PO and the dev. team during the sprint? There should be no surprises for the PO at the sprint review
                  Message 8 of 11 , Jul 6, 2012
                  • 0 Attachment
                    Andrei,

                    Could it be a lack of communication between the PO and the dev. team during the sprint? There should be no surprises for the PO at the sprint review and the PO must work with other stakeholders to collect and understand the requirements before they are included in a sprint, so that the PO can answer questions from the dev. team.
                    Is there a problem that the review results in more stories the following sprints? The keyword with the sprint review is "review". Too many (my org. included) focus too much/only on the demo. Review the work that has been done and make a plan for the coming sprints. I don't see that there is a problem if this results in more stories in the following sprints, as long as this is not an effect of stories not being completed or misunderstood.

                    --- In scrumdevelopment@yahoogroups.com, "momofromthablock" <andrei.berechet@...> wrote:
                    >
                    > Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.
                    >
                    > This leads to long and tensioned demoes and also to additional development after the demo.
                    >
                    > Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?
                    >
                    > It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)
                    >
                    > Any other tips or ideas on this?
                    >
                    > Thanks
                    > Andrei
                    >
                  • Simon Morris
                    ... I have a very similar problem. My approach is to give my stakeholders a sneak peek as soon as the story is nearing completion. I take feedback at that
                    Message 9 of 11 , Jul 6, 2012
                    • 0 Attachment
                      On 5 July 2012 10:48, momofromthablock <andrei.berechet@...> wrote:
                       

                      Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.

                      This leads to long and tensioned demoes and also to additional development after the demo.

                      Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?


                      I have a very similar problem. My approach is to give my stakeholders a "sneak peek" as soon as the story is nearing completion. I take feedback at that stage (even if it is during the sprint) and if the modifications are manageable roll them into the story by adding tasks.

                      Anything of any size or complexity goes into the backlog for a future sprint. 

                      Not ideal but it has improved my chances of having a clear run at the Sprint demo.

                      Thanks

                      Simon 
                    • loobyloo649
                      Hi Andrei, Is it the PO or other customers who are giving this feedback during the demos? It seems to me that there is either a lack of communication between
                      Message 10 of 11 , Jul 8, 2012
                      • 0 Attachment
                        Hi Andrei,

                        Is it the PO or other customers who are giving this feedback during the demos? It seems to me that there is either a lack of communication between the PO and team during the sprint, or a lack of communication between the PO and the customers. The PO should be accepting each user story as it is complete, therefore the end result should be what the PO expected.

                        If this is happening, then I assume that the problem is that what the PO is expecting and what the customers are expecting don't match up which would be a bigger problem, and not one that more QA etc is likely to fix.

                        Can you provide a bit more info?

                        Thanks,
                        Laura

                        --- In scrumdevelopment@yahoogroups.com, "momofromthablock" <andrei.berechet@...> wrote:
                        >
                        > Hey folks - I'm working with a team where there's a lot of back and forth during the demo re: how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.
                        >
                        > This leads to long and tensioned demoes and also to additional development after the demo.
                        >
                        > Any idea how to circumvent this? Specifically do you have any tips on catching these things before the demo?
                        >
                        > It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)
                        >
                        > Any other tips or ideas on this?
                        >
                        > Thanks
                        > Andrei
                        >
                      • Charles Bradley - Scrum Coach CSP CSM PSM
                        Andrei, I m reading the context right, my strong suspicion of what would help is this: * Whoever is making the comments about the tiny things , so long as
                        Message 11 of 11 , Jul 20, 2012
                        • 0 Attachment
                          Andrei,

                          I'm reading the context right, my strong suspicion of what would help is this:
                          • Whoever is making the comments about the "tiny things", so long as that person is a valued stakeholder or PO, should be getting involved earlier.  Possibly as early as Product Backlog Grooming, a few days before the next Sprint, or maybe even earlier.  If the tiny things are UI related, said person should look at the UI as soon as the developers have done a first shot at the UI.
                          • More QA often helps, but only if these things are something that a tester focused person would actually catch.  i.e. defects or other glaring things a tester might catch. If there are defects that are showing up in the Sprint Review, then it sounds like there is a different cause than just "tiny things that can't be nailed down in acceptance criteria."  More testing or perhaps better acceptance criteria(Product Backlog Grooming) might help here.
                          • In my view, and the view of many others, the PO should be "accepting" stories as "done" *during* the sprint, as soon as the dev team thinks they are done.
                          I realize I didn't say things much different than what has already been said in this thread, but I want to dig deeper on this.
                           
                          A "tensioned demo", IMO, is a good thing to happen, but only if it happens once or twice in a row.  The first time or two in a row, it means that *Scrum is working!*  That is to say, transparency and inspection are occurring.  That's awesome!  If you're making changes as a result of said actions, then you're also adapting, and that's awesome too! But I sense something more from you -- the desire to get even better at what you're doing.  The ideas above, along with those on this thread, should give you some idea of how getting better might look.  I think it's always important to remember that a Sprint Review is more than a "demo."  It is an "improvement loop."  Yes, you should try to improve the product increment, but look deeper than that.  A Sprint Review is a chance to improve more than just what shows on the surface of the product/software.  It is a chance to dig deeper and focus the practices(in the retro) that led to that product increment.  You are absolutely, 100% on the right track.  I hope you and your team will work to improve your practices, and please do not forget to celebrate a sprint or two or three down the road.  Once the tension subsides in future Sprint Reviews, in a retro, shock everyone by saying "You remember that bad Sprint Review last month?  Did you notice that this last review went so much better than that one?  We should celebrate!"  Then get your team out for a celebration, so that the culture of improvement is seared into their brain's muscle memory.  We must celebrate our wins and good deeds, so that the good deeds will continue.

                          -------
                          Charles Bradley
                          http://www.ScrumCrazy.com




                          From: momofromthablock <andrei.berechet@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Thursday, July 5, 2012 4:48 AM
                          Subject: [scrumdevelopment] view/track the features developed (and their impact) before the demo

                          Hey folks - I'm working with a team where there's a lot of back and forth during the demo re:  how the developed features are supposed to work. Not at the story level or at the big feature level, but on tiny little things that are almost imposible to pin down in the acceptance criteria or in the story itself.

                          This leads to long and tensioned demoes and also to additional development after the demo.

                          Any idea how to circumvent this? Specifically do you have any tips on catching these things  before the demo?

                          It just popped into my mind while I was writing this that QAing the features more thoroughly and ironing these things out could be one possible solution to this issue :)

                          Any other tips or ideas on this?

                          Thanks
                          Andrei



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

                          To Post a message, send it to:  scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                          <*> To visit your group on the web, go to:
                              http://groups.yahoo.com/group/scrumdevelopment/

                          <*> Your email settings:
                              Individual Email | Traditional

                          <*> To change settings online go to:
                              http://groups.yahoo.com/group/scrumdevelopment/join
                              (Yahoo! ID required)

                          <*> To change settings via email:
                              scrumdevelopment-digest@yahoogroups.com
                              scrumdevelopment-fullfeatured@yahoogroups.com

                          <*> To unsubscribe from this group, send an email to:
                              scrumdevelopment-unsubscribe@yahoogroups.com

                          <*> Your use of Yahoo! Groups is subject to:
                              http://docs.yahoo.com/info/terms/



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