Ideas to keep user stories small

Question

There seems to competing best practices for user stories that I have not been able to come up with a way to deal with. Mainly:

• Keep user stories small.
• User stories should deliver customer values and therefore engineering focused item such as refactoring should not be separate user story and should be part of on-going work.

I feel like it's hard to achieve both of these at the same time.

For example, sometimes you need to refactor things. Some code is complex and just takes time. If it's done as part of the feature user story, then that user story will get bigger. But the refactor should not be a user story since it doesn't deliver customer values. You could argue that maybe we shouldn't let the code got checked-in in the first place, but requirement changes and therefore assumption changes so I don't think that's realistic expectation.

Another example could be dealing with starting a new project; we need to setup the repository, the project, the CI/CD pipelines. All of these are infrastructure work items and does not deliver any direct customer values. I guess in this case, we could use "engineer" as the customer but there are some debate out there whether that's a good practice or not.

Now I could bend the rule and have these as user stories. But I am curious if people are following the scrum rule strictly, is there tips and tricks to achieve both of these requirements?

Answer 1

Scrum does not prescribe any format for the Product Backlog items. So your Product Backlog can contain user stories but also any other kind of items.

As you are saying user stories should deliver value, typically meeting the INVEST acronym but your Product Backlog can contain items related to make functionality possible, such as upgrading libraries, implementing a log system or whatever help the team to potentially release the product. Taking into account that in your Product Backlog there will be bugs too, so it´s not just about new functionalities. So don´t fool yourself making up users who don´t exist.

Being saying that, usually a big refactor is a smell of a problem not tackled at the proper time (generating a high technical debt, a weak DoD and so on). That´s the reason many authors say that you should refactor at the same time your are developing new functionalities (your code should be in good form).

Finally, if you are in such a scenario that you need a big refactor, my advice is to try to decompose the refactor in small pieces and create a good harness of test to refactor with confidence.

Answer 2

I can think of several ways you can cut stories. However, keep in mind that these are ideas that can work but can also make no sense depending on the work. I only want to share my experience.

• think about the three basic areas: User Interface, Data Calculation, Data Retrieval, try to cut the story along these lines
• if you have to do repetitions, create a story for each iteration
• try to do the first implementation as basic as possible, then create more stories for upgrading and fine tuning
• even if a story seems to be straightforward, try to cut it; it is amazing how much better you can discuss as a team about smaller items and how much better you can refine it, and you it forces you to think about the details and this really can make a difference