DEVELOPER

Story segmentation (1/4): It’s an art and we need developers for it

19/06/2024

Good morning.

(Picture:

Stephan Mintert

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.

JavaScript: HTML5 2.0 says goodbye to Internet Explorer

Dear developers, I’m wondering if you are involved in story sharing in your job? At what regular intervals does it happen? How important is it to you? How does it support you (or not)? What do you value about it?

I am asking (myself) these questions because I want to write a few articles on this topic. In this article I explain my motivation and shed light on the complexity of the topic. Three more posts follow.

Storytelling is an art. How do I arrive at this statement? I think successful storytelling requires several ingredients, all of which are rarely present. Here is my list:

Development teams should be involved.
You need a proper user story. Not a random Jira ticket that is arbitrarily given a “story” ticket type. What makes a “proper” user story can range a lot. If you want to talk about it in your team, those are Investment Criteria A good impulse for dialogue. That means: I would not view the investment criteria as standard; but they are very good.
Professional craftsmanship is required. What I mean by this is that you can practice breaking down the story.
Creativity helps to deliver good results. To be creative in this task as a developer, you need to understand the business or at least the purpose of the original story from a business perspective. Here it is necessary to make it clear to the PO what is the significance of the user story to be split for the company.
The correct timing within the workflow is important because the timing determines which people are involved.

While talking to my colleagues, I noticed a point I had not initially considered: if development happens in component teams, there is a high probability that the teams will not see the user story. In general, no user will need a partial implementation. Value arises only from the integration of the parts.

So many topics. There are too many for one blog article and there are already good articles about some of them. So I will limit myself to two aspects: What follows from the splitting? and. Who splits the user story and when? (around What, Who, When? (This is discussed in the following post.)

Before we continue the topic in the next post, a disclaimer: when I hear or use terms like user story and story splitting, I automatically assume an agile or to-be-agile way of working. This is no longer a given because many terms have long been used outside their original context and far from their original meaning. On the one hand, this ensures that excellent concepts no longer work and, on the other hand, that communication about causes and solutions is not successful. To ensure that this does not happen here, I would like to specifically point out the (more or less) quick context.