4

Changeability is a quality attribute of requirements that is emphasized in some classic literature. To get changeability of requirements, they must not be redundant.

However, when dealing with requirements in Scrum, some practices will inevitably lead to redundant user stories. For example, if a software shall have a number features that are similar from a technical perspective, but the user has a different path in the UI for each feature: In order to keep the stories small (INVEST), I would create different stories which are only slightly different, or possibly even equal only with different acceptance criteria. Now, when the business requirement changes, I have to make sure to update all redundant stories accordingly.

Normally, this would be manageable. After all, there should not be a large number of open stories, but just enough to fill a small number of upcoming sprints. In practice ("Scrum, but..."), customers may insist on a breakdown of a large number of requirements for planability. But also large-scale Scrum may lead to a situation where there are a lot of open stories.

Can a long list of open stories be managed without losing the benefits of Scrum?

Improve this question
4
  • IMHO you are overthinking this. Changing the requirements description of a dozen user stories in the backlog requires a fraction of the time of implementing only a few, or just even one of them in code. How often, in reality, did you encounter a situation where you had to rewrite so many user stories that you felt it became unmanageable?
    – Doc Brown
    Nov 1, 2018 at 20:25
  • Hi Max, I'm curious about this statement: "customers may insist on a breakdown of a large number of requirements for planability". In my experience there are other ways to plan without decomposing large amounts of the backlog.
    – Daniel
    Nov 1, 2018 at 21:54
  • To clarify the scale: I would estimate the breakdown will eventually lead to a number in between 500 and 1k stories, plus around 2k acceptance criteria (GivenWhenThens). Because we are developing a product, we also have to deal with changing business requirements from multiple customers.
    – Max Hohenegger
    Nov 2, 2018 at 13:36
  • Hi Daniel, I suppose the vanilla Scrum approach would be to break down just enough to fill 2 or 3 sprints with stories, while keeping (and estimating) the remaining requirements on epic level. For historic reasons I don't want to get into, we have to do the full breakdown in advance in this case. But I am interested in what disadvantages this could bring, compared to any other approach that you have in mind.
    – Max Hohenegger
    Nov 2, 2018 at 13:47

1 Answer 1

Reset to default
5

It sounds like this should be covered by grooming.

Constant change means that stories often need to be corrected, expanded, split, condensed, joined, re-estimated etc.

It is a good idea to groom all tasks periodically. Before planning is the ideal time but it should happen regularly or as often as is required.

Improve this answer
4
  • We do refinements, and it sounds like the right meeting to do this, but because of the scale of product backlog that we will have, I'm afraid it could take too long or that we miss something. Are you aware of any tooling that could help with this?
    – Max Hohenegger
    Nov 2, 2018 at 13:59
  • @MaxHohenegger I guess your first port of call would be your issue tracking system e.g. Jira, TFS etc (assuming you have one).
    – Robbie Dee
    Nov 2, 2018 at 14:14
  • Unfortunately, I could not find a plug-in for Jira that would directly support this. Hence, I prototyped a tool that would help me in finding similar stories and acceptance criteria in a list that I could export from any tool. This gives me sufficient confidence to continue with our current approach, though I want to leave this open to encourage additional answers. I still hope to see either a process or a robust tool-based solution that has been tested in practice. Otherwise, I'll get back to this with our experience report. gist.github.com/Treehopper/a2500ea8d594890b9eba3c870a8113e2
    – Max Hohenegger
    Nov 5, 2018 at 11:56
  • 1
    @MaxHohenegger We've typically just adopted a flag approach - if it is set, it has been groomed. This may get unset at a later date if further information comes to light. Might be worth asking a follow up question - other teams may have a better solution.
    – Robbie Dee
    Nov 5, 2018 at 13:01

Your Answer

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

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