Increment and splitting stories "horizontally"
Hello,
I am scrum master in a team that has been working together for over a year now and I have recently joined.
What I have seen is that they write the stories according to the work steps, meaning there is one ticket for architecture, one for specification, one for implementation and one for testing. They also work on those items over multiple sprints. I have told them that this is (in my opinion) not the way to do it since the tickets do not deliver functioning software or add customer value when considered as a standalone ticket.
One of them said that they are indeed increments since they add up to the final delivery and they adhere to the set DoD. The delivery date itself is set as a milestone from our customer, so they do not see the need to finish the individual stories earlier and rather work on them piece by piece.
The DoD is pretty basic and allows for that kind of stuff. It does not even say anything about testing, it's mostly stuff like
- During the documentation, attention was paid to spelling.
- Follow-up tickets were created for persistent findings.
You get the idea.
My vision is that implement those stories from start to finish in one sprint. Architecture, Testing, everything included and the story is only done once it is tested and otherwise working, not if the acceptance criteria are done and the spelling is correct.
Personally, I would talk to our PO/Project Lead and ask him
1. if we even need scrum and
2. if he wants me to go through with my vision.
This is just for my own mental sake :)
How would you go on about this? Is this a mandatory change that needs to happen or am I overthinking it?
Should I let the team decide if they want to do it?
"Force" it together with the PO and set the DoR rule accordingly?
I need your help and a little perspective from you :)
Greetings
Is this a mandatory change that needs to happen ...
There is no such thing as a "mandatory change" in a self-managed, self-organizing team.
Should I let the team decide if they want to do it?
Yes, then make it a habit to occasionally suggest it as a topic for discussion at Refinement.
...set the DoR rule accordingly
What is the Definition of Ready rule? I have never seen this mentioned in the Scrum Guide.
Personally, I would talk to our PO/Project Lead and ask him
And why would he be responsible for a decision like this when a Scrum Team is self-organized and self-managed? There is no one in a position of authority.
What you have described is something that you, as a Scrum Master, sees as a potential problem to the teams agility. It is not your responsibility to solve it. In fact, you may be the only with this opinion. As a servant-leader, you should be discussing this with the team. Better understand why they do not see this as an issue. If you have proof it is an issue, you should be sharing this with them. However, you and no one else has the authority to make it mandatory or force them to change.
I would challenge them to explain to me how the order they choose to work helps to gain early feedback from the stakeholders that will allow them to adjust if necessary. That is one of the benefits the Scrum framework provides with events and artifacts designed to illicit feedback and make work apparent. And in my experience is usually the thing that is missed by working in the manner you described.
The delivery date itself is set as a milestone from our customer, so they do not see the need to finish the individual stories earlier and rather work on them piece by piece.
That's quite a leap-of-faith they're taking before getting an empirical outcome. If the product is complex with significant unknowns, this approach could prove expensive. Can your customer afford the risk, and the price of any subsequent remedial work?
In Scrum, the milestone for a delivery date is the end of each Sprint. That's the maximum leap-of-faith anyone is invited to take, and perhaps even fund, before obtaining a valuable and immediately usable result.
If the product isn't complex -- or your customer is rich enough -- then perhaps they don't need Scrum.
Daniel, thank you for your perspective, it helps me a lot.
Personally, I am struggling with the question if we really need scrum on this project. It is a bit contrived.
They don't see it as an issue because there is no need for feedback from our customer. We work for one of the automotive OEMs and they just give us the list of requirements and we implement it. Yes, there are a few obstacles in the way but at the end of the day you know when the signal from the brakes gets routed correctly.
When I told them about releasing fully implemented requirements every sprint they told me that it's too big and they don't need to, because they are using the sprints to build up to the releases every few months.
And to me that's the key right there: They don't NEED to. There is no benefit. There is no feedbackloop that needs closing. They doubt the benefit of the sprints and frankly so do I.
It creates more overhead with planning, estimating... The review is simply for the other teammembers to get up to speed, because they like to see what the others have done. Totally fine to want this, is it a scrum review though?
If the product isn't complex -- or your customer is rich enough -- then perhaps they don't need Scrum.
That's what I'm struggling with.
If you'd ask them, its complex. If you'd ask me, its complicated, not complex.
I was asked to tell them the value of scrum. Told them it's to have new software that's usable every sprint and to have a feedback loop with the users, not just the developers.
They said that they don't need to deliver something every sprint. Only at the milestones does it need to be complete.
I guess my personal problem here is that scum is used as a means of managing the people and lacks the focus on value creation with every sprint. That's not how I want to work, but that is just what I want from the job. It works fine in my other team. In this case however scrum feels...wrong?
Would you still use scrum in that case or advocate for something else?
I guess my personal problem here is that scum is used as a means of managing the people and lacks the focus on value creation with every sprint.
I know that was a typo but it might also be considered a freudian slip. Sorry, couldn't stop myself. I actually laughed out loud when I saw that. My dogs are still looking at me like I have gone crazy.
Seriously, you might be better off to use something like Kanban on that project. It will still give transparency to what is happening but doesn't depend as much the feedback loop. You can still do demos to others as warranted. And it will still allow the Developers to self-organize to get the work completed.
Would you still use scrum in that case or advocate for something else?
Well, Scrum isn't being used in the first place. People are doing something else, from which they aren't going to get Scrum outcomes, and which apparently aren't even expected at all.
A Scrum Master has a duty of care to the framework. When we play fast-and-loose with Scrum, or are complicit in doing so, we reduce its currency. In your situation there are fast-and-loose things going on, because the vocabulary of Scrum has been co-opted, corrupted, commandeered and bastardized into something else. Moreover, the organization has sanctioned it. Good luck on preserving the integrity of Scrum with those other teams you mention.
I wouldn't go so far as to "advocate something else". I'd just recognize that something else is already happening, in truth, and we need to be transparent about that fact. Calling it Scrum is an obfuscation which helps no one, so to begin with, I'd advocate just being honest and calling it something else.