Question

We use Scrum. We are experiencing problems during sprints when we find the user stories are not sufficiently granular to capture the effort required to complete the sprint.

In particular, we find that we are supplied with UI wireframes that contain much more complexity than the original stories would have implied (e.g. functionality duplicated for usability reasons). This leads to the burndown chart looking like everything is completed on the final day of the sprint.

We spend the Monday at the start of each 2-week sprint going over the stories as created by the project team, during which time we typically refine the stories a little and break them down into tasks, estimating the hours for each to create the burndown chart. During this day it doesn’t feel like we have time to meaningfully improve the quality of the stories.

How best to break the cycle of incomplete / insufficient stories for our sprints?

Is this a failure of the project team to nail down the stories sufficiently at the outset, or should we (i.e. the dev team) take some of the responsibility?

Answer 1

So are you saying that:

1. Customers/users talk to project team
2. Project team writes stories and creates wireframes
3. Development team breaks down stories into tasks and estimates

Is there a possibility of the development team actually talking to the customers/users? User stories are sometimes seen as a way to kick off a conversation, as opposed to requirement documents/specifications.

EDIT: Some links:

• A user story is to a use case as a gazelle is to a gazebo
• Six Features of a Good User Story – INVEST Model
• The Customer is Always Available

EDIT: Martin Fowler made a blog post yesterday on ConversationalStories that covers this far better than I did.