AGILE IN ACTION

Friday, 10 February 2006

User stories part 3: Using spikes to help estimate user stories

Posted by Simon Baker

Read our latest thinking on spikes.

A user story containing unknown elements should be split into a spike to investigate the unknown elements plus a story to develop the functionality. This enables the customer to prioritize the research separate from the implementation of the new functionality.

Without a spike to substantiate the estimate for the user story, the customer may incorrectly assume the estimate to be valid and prioritize the story accordingly. Facing a spike and an associated story, the customer should prioritize the spike ahead of the story to obtain a more reliable estimate for prioritizing the story.

Next post in this series:

  • User stories part 4: Collaborating to write acceptance tests

Previous posts in this series:

Creative Commons Licence

Recent Posts

  1. System failure is inevitable so design for a fast recovery
  2. Delight comes as a surprise in unexpected places
  3. Help create business agility. Bake quality in
  4. Governance - Friend or Foe?
  5. 70% Forum
  6. Measuring purpose. Measuring customer delight
  7. Stop pushing features and start delighting users
  8. Lost without a goal
  9. Emotion creates the common language
  10. Five sneaky ways to kill an initiative

Archives

  1. 2012 (16)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
  7. 2006 (128)
    1. December (16)
    2. November (26)
    3. October (7)
    4. September (11)
    5. August (7)
    6. July (7)
    7. June (4)
    8. May (4)
    9. April (4)
    10. March (4)
    11. February (14)
      1. Don't be afraid to make mistakes
      2. APLN and collaborative leadership
      3. Scrum ba
      4. Ten-minute build, continuous integration and developer rhythm
      5. User stories part 3: Using spikes to help estimate user stories
      6. User stories part 2: Adaptive planning
      7. User stories part 1: What is a user story and who writes them?
      8. Ba
      9. Watch out for the mini-series
      10. Ideal time vs. story points
      11. Making the quality-factor visible
      12. User stories and tasks
      13. Knowing when you're done
      14. Switching pair-programming partners
    12. January (24)
  8. 2005 (63)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (40) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)