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.
In the last post I wrote about splitting the story too early. Today it is too late to split, which to me means no splitting.
What is the conclusion from this? It is simple: you give the team a “big” story and they start planning with it. This results in all the disadvantages of too large work packages. For example: it takes too long to complete a task. You get late feedback for your work, the return on investment is too late, you realize too late that you are working in the wrong direction, and so on.
Last year I was able to see tickets from a team that was already in its seventh sprint with no end in sight. When asked about this, I was told that the team agreed that tickets could be carried over from one sprint to the next. I don’t mind this, in line with the motto that “everyone is the master of their own destiny”. However, no one was excited about the many meetings on the calendar.
In my opinion, this contained all the Scrum nonsense. This is what Scrum events become if you work like this. For tickets whose Sprint duration is longer than fourteen weeks, I clearly don’t need Sprint Planning. Saying from 14+ weeks in the Daily Scrum that a ticket is being worked on now has nothing to do with the intent of the meeting. And repeatedly saying in the review that there has been progress but no results is unnecessary. I don’t even need to talk about Sprint Goals and Product Goals.
If you want to work like this, you should at least be honest with yourself and free your calendar from ballast. Unless you need useless meetings to be able to put “new work” and “smartness” in the job ad. However, the price for this is very high.
My advice is usually different: whatever you do, do it well! So either avoid unnecessary meetings or – my favorite – split them up sensibly so that it’s possible to achieve success in shorter intervals.
conclusion
At the end of a short series on the topic of story splitting, my conclusion is this: there is no way a development team can learn to split user stories. There are probably a lot of good sources on the Internet about this, and perhaps a series of articles on this blog is worth it. The team should request their involvement if necessary. However, if you do without it, there is a high risk that the work will become a feature factory.
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)
