Story Breakdown (3/4): Not Without My Developers

Good morning.

Advertisement

Stephan Mintert works with his clients to improve corporate culture in software development. He currently sees the greatest potential in leadership; regardless of the hierarchy level. He gave himself the task of leveraging this potential with a few career changes. Originally coming from a computer science background with many years of consulting experience, he initially founded his own software development company. He found that leadership has to be learned and good role models are rare. It became clear that the greatest need for support for his clients in software development was not in producing code, but in leadership. So it was clear to him where his company Kutura was going: improve leadership so that the people who develop the product can grow and develop themselves. Stephan has been writing for Heise since 1994, as a long-time freelancer for iX.

OnePlus Nord 4, a 5G phone with a metallic design

In the casual episode about user story splitting, I answer the following question:

Who is involved in the division and when does it happen?

I’ve essentially noticed two anti-patterns that, in my opinion, should be eliminated:

• Segmenting too quickly by business analysts, product owners, product managers or comparable title;
• To be distributed very late, i.e. never.

Today’s post is about the first point; another article will shed light on the second aspect.

What does too early mean and what is the problem with it? Too early means that developers are not involved. Even if the split result is “good”, it is not good to exclude developers.

There is a risk of otherwise avoidable technical debt being created; namely when the scope of the smaller user story resulting from the split is so small that the larger (and known to few people) context in the smaller story is no longer visible. Consequential damage (technical debt in the original sense) can be avoided after the split by discussing the resulting stories coherently (e.g. in refinement) and keeping the connections in mind during implementation/sprint planning. However, developers often cannot start with this because they need to know that the story they are currently looking at has a larger context. But splitting may have hidden that. Without context, developers become mere delegated agents in a feature factory. Rather than explaining context to them after the fact, I think it is more worthwhile to involve them in the split so that the technical information is on the table.

A special case is working in component teams. There is a high probability that the development teams will not see the original user story at all. This can be counteracted by properly involving all component teams in the breakdown. I have good experience with one Refinement process based on LeSS (Scrum at scale). Make.

The Story Splitting miniseries consists of four parts:

1. It’s an art and we need developers for it
2. Decompose into components?
3. Not without my developers
4. Waterfall without a plan

(RME)