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

Re: [scrumdevelopment] technical items in product backlog

Expand Messages
  • Rafael Sabbagh Armony
    Gap, in fact, in the Certified ScrumMaster training I ve learned that spikes take place in the sprint before, so it can be used to better estimate
    Message 1 of 14 , Sep 25 12:27 PM
    • 0 Attachment
      Gap,

      in fact, in the Certified ScrumMaster training I've learned that spikes take place in the sprint before, so it can be used to better estimate stories/tasks in the next sprint.

      Still, I don't know yet how to handle them well. This sprint, we've created a generic story Spike where each task is a specific spike. But I didn't exactly like that solution...


      --Rafael

      (I'm new here!)


      On Thu, Sep 25, 2008 at 3:43 PM, Gary Passero <gpassero@...> wrote:

      Tim, et al-

      This implies that the task breakdown occurs before story poker, right?

      gap

      On Mon, Sep 22, 2008 at 5:40 PM, Tim Walker <walketim@...> wrote:

      That is precisely what I am suggesting and makes the benefits clear!

      What would be a mistake, IMO, would be to take:

      User Story 1: As a helpdesk system user I need an ITIL v3


      compliant form to support fulfillment so we follow a client support
      market standard.

      and make:

      User Story 2: Learn the process of support fulfillment from ITIL
      v3 Good Practice Library

      ...for the reasons posited above. This is what some are suggesting and
      I'm not a fan of it.

      Tim


      On Mon, Sep 22, 2008 at 3:23 PM, MaurĂ­cio A. Vernaschi
      <mauricio.vernaschi@...> wrote:
      > Tim,
      >
      >
      >
      > Do you think it is a good practice to split an user story in tasks so one of
      > these tasks is to acquire knowledge = a task that leverage a spike known by
      > the team? What do you think? Maybe create a "spike backlog"?
      >
      >
      >
      > Sample:
      >
      >
      >
      > User story: As a helpdesk system user I need an ITIL v3 compliant form to
      > support fulfillment so we follow a client support market standard.
      >
      >
      >
      > Let's suppose nobody in the team knows ITIL v3, then the tasks would be:
      >
      >
      >
      > Task 1: Learn the process of support fulfillment from ITIL v3 Good Practice
      > Library
      >
      > Task 2: Create the form prototype and specialize GUI
      >
      > Task 3: Code
      >
      > Task 4: QA
      >
      > Task 5: Doc
      >
      >
      >
      > Any idea?
      >
      >
      >
      > Regards,
      >
      > MaurĂ­cio A. Vernaschi
      >
      >
      >
      > ________________________________
      >
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Tim Walker
      > Sent: segunda-feira, 22 de setembro de 2008 18:07
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] technical items in product backlog
      >
      >
      >
      > Spikes are time boxed tasks for learning, due dilligence, etc. in
      > pursuit of a story of value. Some people create new stories for them
      > which I am advocating against for several reasons, including creating
      > havoc with velocity based on some of the following rationale...
      >
      > 1) working software is the primary measure of progress, not working
      > knowledge
      > 2) in theory a team could have velocity and produce no value
      > 3) a spike is not functionality in the SW, it is not a statement of
      > functionality from the perspective of a user
      > 4) too easy to start using them for engineering only tasks
      > 5) all stories and all development require new knowledge to some
      > degree, rather have this affect the velocity
      >
      > Tim
      >
      > On Fri, Sep 19, 2008 at 6:39 AM, Gary Passero <gpassero@...> wrote:
      >> Tim,
      >>
      >> What are spikes?
      >>
      >> Gary
      >>
      >> On Thu, Sep 18, 2008 at 4:18 PM, Tim Walker <walketim@...> wrote:
      >>>
      >>> Personal choice is:
      >>>
      >>> 1) always tie task to some user story of value and let it affect
      >>> velocity for that story.
      >>> 2) spikes should never be stories.
      >>> 3) refactor in the course of developing value not for refactoring sake
      >>>
      >>> Just my .02.
      >>>
      >>> T
      >>>
      >>> On Thu, Sep 18, 2008 at 3:00 PM, Angela Druckman
      >>> <angela.druckman@...> wrote:
      >>> > Hi Gary -
      >>> >
      >>> > I sometimes have "purely" technical items in a backlog. i don't see any
      >>> > problem with it if they are bringing you business value, which it
      >>> > sounds
      >>> > like they would be. You can work with your Product Owner to decide how
      >>> > best
      >>> > to incorporate such items. Sometimes we keep a side list of these items
      >>> > and
      >>> > work on them when we are in that part of the code making other changes
      >>> > (we
      >>> > include them as tasks in other stories). That way you get two backlog
      >>> > items
      >>> > but only touch the code once.
      >>> >
      >>> > Still, I don't think there is anything wrong with technical backlog
      >>> > items if
      >>> > the PO says they have business value. it sounds like you have some
      >>> > clean
      >>> > up
      >>> > work to do and the sooner you start working through it, the better--
      >>> >
      >>> > --Angela
      >>> >
      >>> > ----- Original Message ----
      >>> > From: Gary <gpassero@...>
      >>> > To: scrumdevelopment@yahoogroups.com
      >>> > Sent: Thursday, September 18, 2008 10:35:12 AM
      >>> > Subject: [scrumdevelopment] technical items in product backlog
      >>> >
      >>> > Hey friends,
      >>> > I'm new to Scrum (couldn't you tell?). My company is just starting
      >>> > it's first sprint in a few weeks. I'm assigned to be the SM, and I'm
      >>> > working with my PO to help create an initial product backlog.
      >>> >
      >>> > Can anyone offer some details on how best to represent a _large_
      >>> > volume of technical debt and technology items in the product backlog?
      >>> > I understand the general principle (thanks, Joe Little!) of trying to
      >>> > slice it, and keep every user story in the backlog business-value
      >>> > oriented (at least to some degree). Our company has *A LOT* of these
      >>> > technical items to work through: some are part of a changing
      >>> > architecture to position ourselves for more features, and some are
      >>> > part of overcoming the technical debt incurred through years of
      >>> > "hacking" on this proprietary codebase.
      >>> >
      >>> > Thanks for your ideas, your shared experiences, and your assistance.
      >>> >
      >>> > Gary
      >>> >
      >>> >
      >>> >
      >>
      >>
      >
      >


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