>
but certainly not all* and probably not even most.*
Yet to find any that can't. I've yet to hear of any either. Usually that's a problem with the people trying to break things down not being used to modeling things differently - not the process. It's pretty common.
I'd love to hear some examples tbh.
> There's nothing magical about being able to partition a deliverable into a sprint's time frame that, by such distinction alone, makes it valuable versus valueless.
Of course not! The point is not that the time-boxing makes it valuable, I hope I didn't imply that, it's that all features that have value should be specific enough to be able to be broken down. If something is too vague it's not a valuable feature because at that point is just pie in the sky spitballing. That's what requirements and grooming is for - to identify what needs to be broken down, expanded on, or specced out better by the Product Owner.
> It's like writing a novel and having two-week deliverables like "complete the arc of the Alice character", versus "write approximately 100 pages".
That would be awful Scrum process. Also the Product Owner is the Sprint Team in a novel but lets pretend they are two separate people for this: here's how that should work in a Scrum system...
- Story: "complete the arc of the Alice character"
- Feedback: Too vague. What IS the arc? What perspective should it be from? Lots of questions, needs to be broken down.
Next, after the product owner has worked out that we're going to hit these beats in a 3 act structure.
- Story: "complete Alice's arc for Act One, with exposition introducing her and the other characters, ending on the inciting incident for the main plot"
- Feedback: Better, but this is really 3 things - the introduction of Alice, the intro of the other characters, and the inciting incident. You should split those up.
Next, the PO has split this up into those three Stories and presents the first one...
- Story: "We need to introduce Alice so the audience can start to get to know her."
- Feedback: Great, this seems low complexity and simple. We have requirements for her backstory? Ok, great, lets work with that. Seems like a Complexity 2 Story.
Then, when Sprint Planning...
- Scrum Master (not PO): "Ok so we were planning on getting this Alice introduction done this sprint, we still ok with that?"
- Everyone: Yup!
- Scrum Master: Ok, lets break this down into tasks of things we want to cover then.."
And then that part of the story gets written. Obviously it's an odd metaphor, but that's kind of how many (not all, at all) professional authors break down a lot of their writing process anyhow. Some are more freeform of course, but many plan a lot too.
The point is - that just because you have a planning step doesn't remove the creative process, it helps you plan better for work. That's all.
Scrum doesn't magically change how you code or what you code, it's just a planning and change management tool that emphasizes incremental steps.