• DocumentCode
    3298772
  • Title

    A Technical Story

  • Author

    Robinson, Nick

  • Author_Institution
    Lab49, New York
  • fYear
    2007
  • fDate
    13-17 Aug. 2007
  • Firstpage
    339
  • Lastpage
    343
  • Abstract
    Across the agile community there has been a lot of discussion regarding the use of technical stories. While the community seems split into two camps of for and against, the majority of extreme programmers favour to define the system using only the traditional customer focused user stories. In some cases the technical story arguments are academic, but our experience report demonstrates clearly why sticking to user stories has its benefits. Our experience using Scrum and XP has been that allowing technical stories into the process can de-rail the ability to deliver constant, measurable business value per iteration, as well as inhibit the planning process. Once technical stories are allowed, the customer and business can be alienated very quickly, especially when they have no engineering background. Furthermore, when problems occur and the technical stories begin to slip, the customer can be left in a very difficult position, not knowing how to re- prioritise or direct the process. It is therefore our intention to highlight some of the pitfalls that can result from using technical stories.
  • Keywords
    programming; software engineering; Scrum; agile development; customer focused user stories; extreme programming; technical story; Fires; Process planning; Programming profession; Project management; Team working;
  • fLanguage
    English
  • Publisher
    ieee
  • Conference_Titel
    Agile Conference (AGILE), 2007
  • Conference_Location
    Washington, DC
  • Print_ISBN
    0-7695-2872-4
  • Type

    conf

  • DOI
    10.1109/AGILE.2007.68
  • Filename
    4293619