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

41910Re: [scrumdevelopment] Small user stories

Expand Messages
  • Jim Schiel
    Oct 14, 2009
      There is definitely a danger associated with slicing stories into pieces that are TOO small. Teams lose the ability to truly collaborate (they can pair, but it becomes quite robotic under these conditions -- "here, give me the keyboard, it's my turn"). Stories this small are tasks and should be swarmed upon by a portion of the Scrum team. In addition, there's the expense of slicing stories into very small pieces. In the end, it costs time (money) to do it and you get no benefit.

      I usually draw the line around something that 2 or 3 people on the team can do in less than a week (or maybe a little more than a week). That usually gives you a good size around which the team can be as dynamic as needed.

      Jim Schiel, CST
      CEO/Owner, Artisan Software Consulting
      Author of Enterprise Scale Agile Software Development

      On Oct 14, 2009, at 10:56 AM, Inanc Gumus wrote:


      After some analysis, we've split our user stories into many small user stories. A story had been estimated at 20 points (and was taken 2 weeks to implement (sprints)). We've split another story which has estimated at 20 points into 10-15 small stories (in average each story estimated at 1 to 2 points). Each story has a business value attached and has a single acceptance criteria. Our velocity btw is 13-15 points.

      A developer from our team having a difficulty, says that: 'having these kind of tiny stories makes us to work very collaboratively which is -bad. Because we'r only working with a single story at the same time, rest of the developers doing nothing just pairing with me (pair? 3 developers on the same machine!). Because they'r completing their tasks in a half days work.'

      What do you think? Is this safe? I've some ideas but first wanted to hear from you.

    • Show all 7 messages in this topic