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

Re: [scrumdevelopment] view/track the features developed (and their impact) before the demo

Expand Messages
  • 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 1 of 11 , Jul 20, 2012
    • 0 Attachment

      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

      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?



      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:

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          (Yahoo! ID required)

      <*> To change settings via email:

      <*> To unsubscribe from this group, send an email to:

      <*> Your use of Yahoo! Groups is subject to:

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