Good morning.
Advertisement
(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.
What happens when you split a user story? Answering this question wrongly leads to a dangerous action whose toxic effects are easily overlooked when viewed superficially. For me there is only one correct answer: splitting a user story creates two or more new user stories that replace the old one. It is not important what you call the ticket type. It is important that the derived, smaller tickets have independent value to someone (outside the development team) (see also). Investment Criteria,
From my observation, this is not a given. Instead, I see teams breaking down the story into so-called work items, i.e. parts whose sum implements the feature desired in the original story. However, the parts have no independent value. This approach is not story splitting at all. There is a term for this type of decomposition: it is planning. Except that it takes place in the planning phase (erroneously) called refinement, not planning. This view can also be found here Description of the plan in the Scrum Guide again:
For each selected Product Backlog Item, developers plan the work needed to create an Increment that meets the Definition of Done. This is often done by decomposing the Product Backlog Item into smaller work items of one day or less.
Anyone who decomposes refinement into technical pieces should (hopefully) annoy the Product Owner, but in any case scare every (business) stakeholder. This makes it difficult to achieve inter-departmental cooperation (business/development) in refinement, as was the case decades ago in the manifesto of Agile software development. Principles demanded.
Business people and developers must work together daily throughout the project.
If there is no cooperation even in an important meeting like Parishkaar, then when else will it happen?
(Picture: Ruben Juarez/Unsplash,
The Story Splitting miniseries consists of four parts:
- It’s an art and we need developers for it
- Decompose into components?
- Not without my developers
- Waterfall without a plan
(RME)
