Splitting Stories by Subtask

I would strongly discourage this kind of splitting, at least in any externally visible perspective or view of work. I firmly believe that a unit of work (in Scrum, the Product Backlog Item) should represent something that is both valuable and deliverable or demonstrable. Splitting a work item into "development" and "test" results in having something "done" that is not valuable, demonstrable, or deliverable.

Now, that doesn't mean that the team can't subdivide a unit of work. For planning purposes, it may make sense. Splitting into "development" and "test" is still problematic since they are very large and may tend to sequential thinking. I can understand splitting work into pieces covering user interface design and development, API design and development, database changes, and integration testing. Some testing can be done on each piece to build confidence, and then the pieces can be integrated. Depending on your tooling, this kind of splitting can also help with Sprint Planning or Daily Scrums. However, until all the work is done and integrated, it's neither deliverable nor demonstrable to a downstream stakeholder. I prefer alternatives that focus on visible units of value.

I'm glad to hear your group pushed back on this kind of twentieth century management thinking and consultant-driven prescription. Good for you. The practice is not only unhelpful, it raises concerns about micro management and the effect on team motivation and self-management.

Splitting a story into a separate "dev story" and "test story" seems simple, but it breaks the way a Scrum Team works. It is a classic anti-pattern. It pushes the team toward phase-based Scrum-er-fall, and neither slice offers any real value or meaningful transparency once you cut the work horizontally.

The moment development and testing are split, the team stops self-managing around a single outcome. Developers swarm the "dev stories," testers wait for handoffs, and work turns into a sequence of dependencies instead of a collaborative flow. At that point, the group is no longer deciding together how to produce something usable. They are managing stages of work. That slows learning, creates queues, and hides the real risks in the system.

The more useful question to ask is: "What outcome are we trying to improve by separating dev and test stories, and does this change make us better at delivering something transparent, usable, and valuable each Sprint?"

If the organization is open to that conversation, better alternatives appear very quickly.

Post here anytime. 

Recently we have had to deal with an order that came from senior management, in which was stated that going forward we should split our user stories a development story and a test story.

That tells a story about how management have lost the plot regarding empiricism and the evidencing of value. A story that isn't Done just kicks the can down the road on having increments of usable quality. It sounds as though the consultant has sold them a pup. Caveat emptor.

Ask why!

Like the previous posters, I don't think it makes sense to split a story into a development story and a test story. This is especially the case if they are implemented in different sprints.

However, you should ask management and/or the consultant what they hope to achieve with this instruction. Why do they think it's better? 
At this level, it's easier to discuss whether this makes sense, or whether another solution would be better.

In my experience, management have a goal in mind when they give such instructions — mostly, at least. They don't just do it 'because someone said so' or for similar reasons. I suspect the 'solution' is not good, and you are right to resist it. However, perhaps the goal is sensible or the reasoning points to a real problem that would be wise to solve.

I could speculate about the reasons management might have had — I can think of several — but that would be pointless.

Once you know the reason, feel free to come back here.
If you don't receive an explanation, then you have another problem with openness and transparency. 

Thank you for your responses. It matches what we presented to management. Basically we said that 

- it increases management of requirements
- that it obscures the actual state of the requirements
- that it encourages silos and disencourages teamwork
- that inconsistant states can exist (Dev - InProgress, but test says "Done")

Apart from a "some people see it this way and some people see if differently" and "this idea is not from me it is from the consultant" we have heard no reasoning behind it. 

My personal opinion is that it is reporting driven. We have quite a few "multi-sprint" use cases at the moment because core-entities and core-relationships are being affected by automation. Where previously it was garanteed that certain relationships where 1:1-n, due to timing problems we have to change it to 1:0-n. This has a massive impact on external services as well as other event based stuff that we do. It's impossible to split these tasks vertically, or by functional area, because it's so fundamental. So we're stuck for a while with over-dimensioned sprint items. Again, my personal opinion, we should change the length of the sprints to match the current work pattern, in order to aim for completion in a sprint, but there are some battles that are not worth fighting. 

Any tips or comments on mult-sprint work items are welcome. These dominate our capacity at the moment. 

cheers

DJ MIC