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

Re: [scrumdevelopment] Re: User Feedback, Quality and Progress Depiction

Expand Messages
  • Hariprakash Agrawal
    Hi, I actually do not see any practical issue with first approach or you can have 2 definitions of DONE (one specific to customer review and another for final
    Message 1 of 6 , Feb 24, 2011
    • 0 Attachment
      Hi,

      I actually do not see any practical issue with first approach or you can have 2 definitions of DONE (one specific to customer review and another for final product). However, you might need to push PO for a better job on PBL. In my most of the consulting assignments, most of the bugs can be attributed to poorly defined requirements.

      I usually suggests 2 definitions of DONE, one for intermediate release (in your case, customer review) and another is before final release BUT I must say that we are usually clear in the beginning itself that when is the final release. If still management (or PO) feels that some low severity, low priority bugs need not be fixed than thats the calculated risk they are taking and I hope that they have done the comprehensive business impact analysis.


      Regards,
      Hariprakash Agrawal (Hari),
      Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
      Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing
      )


      On Thu, Feb 24, 2011 at 12:46 PM, kbs_kulbhushan <kbs_kulbhushan@...> wrote:
       

      Hello Malcolm,



      > I tend to define bugs like "can select dates in the past" as
      "previously
      > undefined requirements"
      Your are right.
      So if we are clear about "Done" for the customer review we could have
      split the story into two and only marked the "must have for customer
      review" as "Done" for the first and another one for the following story
      which can be prioritized later (maybe color coded as suggested by Ron
      earlier)


      > On that note, there was one thing you said that has a serious smell,
      > "we cannot arrive at a possible release date with outstanding bugs"
      > Is this your belief, the company policy or something else?
      I was referring to only P0,P1,P2,P3 defects only, it is company policy
      and my belief too. Truthfully there are deferments to next release but
      those are conscious decisions.


      > Lastly, have you and your team yet defined your quality bar?
      > requirements must be met before a story is considered done
      We do define the "Done" and have a quality bar in that we do not mark
      something as "Done" till it has a P0, P1 or P2 outstanding. The PO
      decides the priority of the defect.

      Regards,

      --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson

      <malcolm.b.anderson@...> wrote:
      >
      > I tend to define bugs like "can select dates in the past" as
      "previously
      > undefined requirements"
      > and suggest that you put them on the backlog for the Product Owner to
      > prioritize.
      >
      > On that note, there was one thing you said that has a serious smell,
      > "we cannot arrive at a possible release date with outstanding bugs"
      > Is this your belief, the company policy or something else?
      >
      > Lastly, have you and your team yet defined your quality bar? What
      > requirements must be met before a story is considered done?
      >
      > Here are some starters:
      > Builds on the developers box
      > Builds in the Continuous Integration test box
      > Breaks no regression tests
      > Has an 85% code coverage
      >
      >
      >
      >
      >
      > On Wed, Feb 23, 2011 at 2:56 AM, kbs_kulbhushan
      kbs_kulbhushan@...wrote:

      >
      > >
      > >
      > > Hello,
      > >
      > > In our current development we want to provide our application to a
      few
      > > customers earlier for review. While testing we do get defects that
      are not
      > > immediate necessary fixes (e.g. user can select a date for an event
      which is
      > > actually in the past) if we accord higher priority to the feature
      > > availability for review to customers.
      > >
      > > How should we track the stories? Should we consider them still "Not
      Done",
      > > if so the progress charts do not show any useful information. We
      could think
      > > of two ways we can handle it:
      > >
      > > 1. We mark defects as P1,P2, P3, P4 and only consider P1+P2 as

      > > necessary for a story to be DONE. P3+P4 etc will be done later.
      The trouble
      > > is we cannot define later - and we cannot arrive at a possible
      release date
      > > with outstanding bugs. One option is to size the bugs
      immediately(though an
      > > additional cost) and add a story whose size increases every day
      we have a
      > > bug.
      > > 2. We split the release into two. One is just for "Customer

      Review
      > > Product". Other is "Final Product".
      > >
      > > We were veering towards the first option, and wanted to know what
      others
      > > would do/have done - faced with this situation.
      > >
      > > Regards,
      > >
      > >
      > >
      >


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