2

One of my teams is struggling with user story sizing.

A couple of weeks ago the stories seemed to be too big i.e. they were dragging along / staying on the board for weeks.

The PO has started to create more granular stories but now the opposite is occurring, there are too many code dependencies between different stories e.g. one dev pushes a story to done, another dev picks up the new story and its so tightly dependent that they both need to unpick the original code and or struggle to merge code.

Does anyone have any suggestions?

Update: Team is using Kanban

Improve this question

2 Answers 2

Reset to default
3

This sounds like your development team is not being allowed to sufficiently discuss the stories in the product backlog prior to moving them into the sprint or iteration backlog. The development team should be able to take stories that are either too big or too small and decompose or aggregate respectively. The team should be discussing this during sprint/iteration planning so that they can identify where they will have internal dependencies that suggest aggregating a set of stories or when they discuss a story they find identifiable sub capabilities that suggest further decomposition.

If the development team is not having a full role in the creation of the sprint/iteration backlog during planning, then you may need to do a course correction on your process.

I just realized you didn't actually say you are using Scrum (which most of this is written for), but for any Agile method that is laying requirements on a development team it would be wise to have them intimately involved with the Product Owner to work toward that balance you're seeking.

Improve this answer
3
  • Thats a good point. The planning sessions seem to be a lot about the PO talking to the team, having a chat and then moving on when in fact we should be more like a little workshop
    – TheLearner
    Commented May 10, 2016 at 12:57
  • Might I then suggest that you look into Scrum (scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf) to provide just a small shift in the view point on how the PO works with the team.
    – Polymath
    Commented May 10, 2016 at 13:01
  • I actually think because we are using Kanban, the backlog refinement sessions are not long or detailed enough. The team doesn't get time to question things.
    – TheLearner
    Commented May 10, 2016 at 13:03
1

I believe you need to INVEST in your user stories.

  • Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable A user story must deliver value to the end user.
  • Estimable You must always be able to estimate the size of a user story.
  • Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable The user story or its related description must provide the necessary information to make test development possible.

This takes practice, but you'll get there. One idea that works well for Kanban is to add a "Breakdown" column to your board. There is no concept of a sprint backlog in Kanban, there's just one product backlog, but this column can serve a similar purpose. By making this a part of your process, you can make your team think about how the stories can/should be broken into smaller pieces of deliverable, valuable, and testable functionality.

Improve this answer
1
  • 1
    +1 for INVEST. You need to pull out the dependencies and do them as standalone stories, ideally as small as you can do to get it done, even if you can only give the result limited testing at that stage. If you have a test function (rather than the devs cross testing each other) you will get push back that they cannot test the dependency stories, but their ire is little compared to the pain of waiting for someone to finish and get signed off one big story that's been holding up a team for a week or more.
    – The Wandering Dev Manager
    Commented May 12, 2016 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.