My stories are too small
We want to have backlog items that are as small as possible. It protects us from the unknown. It prevents us from having to re-work too much code if rejected, and limits the effect of wrong estimates. It allows us to be predictable.
In the same time, backlog items must have a meaning. We want to be able to release something valuable. Done-done also means useful. If it’s not, how can you adapt your backlog to actual needs? What’s the value of your high-level estimates? If something considered as done is in fact half-done, how can you release it? Splitting stories also means you can stop at the end of the first part.
I’ve never found the right recipe. And I just bumped into this situation again. The need is something like “I want to use an object of type A in screen B”. To use this object, I must first select it, so I need a selection screen. Then I need a select button that actually allows to update screen B given the object selected. The thing is… just implementing the selection screen doesn’t fit in the iteration.
Note: we are in an iterative mode but the issue would have been the same with a flow. The story is too big, and we couldn’t split it.
Only implementing the selection screen doesn’t make any sense. If we had to release at the end of the iteration, the user would have a selection screen with a disabled select button that says “to be continued”.
We chose the smallest issue: split it and deliver something that is not usable or useful at the end of iteration, but deliver something anyway. We prefer feedback than nothing, partial waste than entirely in stock. But still I’m not satisfied, like always in this situation. And finally we have this ugly story: “I want to use an object of type A in screen B, part 1”. So…
Feedback is warmly welcome. Have you encountered this situation? What do you suggest?
AAAgile 
Sounds like your definition of “value” needs work. Many software functions cannot be built entirely in a single sprint. In some cases, a complex function will span 2 or more releases. That’s okay!
If a function is partially implemented and doesn’t do anything meaningful, it still has value. Simply hide it or gray it out until it proves useful. QA can still validate what has been implemented and the PO can still sign off on it.
We sometimes get overly caught up in trying to deliver a “potentially shippable product” at the end of each sprint. It sounds good in theory but it’s almost impossible in practice. That’s why focusing on “release functionality” is better than focusing on “sprint functionality”.
I hope this helps.
Thanks for your comment Vin. Indeed, it helps a lot.
Happy to see I’m not the only one in this case (though I actually had the problem on every single project I worked on), and not the only one to get to this solution. I guess the functional completion should be followed through yet another level of items like epics. That’s the kind of stuff I would have preferred avoiding, but what matters is reality. You confirmed I was on the right track, up to me to convince the team now.
And I agree about your comment about “value”. That’s the problem with buzzwords: there are lots of “value”s. Being able to gather feedback, or to evaluate team’s predictability, is in itself valuable.
Again, thanks a lot.
Hey Antoine, great scenario / question!
I believe there are two answers – the general case, and the specific case.
In the general case, you’re starting out with two constraints in story definition: (1) valuable / potentially shippable product, (2) stories must be contained within a sprint. Two orthogonal constraints, and every team will face the situation where you can’t simultaneously resolve both of them – you can’t make it smaller, without eliminating the value (or jeopardizing the release). In general, you have to pick which constraint makes the most sense (for _your_ team, for _this_ story) to violate. Scratch out the pros and cons on a whiteboard, and pick one. Once you believe you are in this “have to violate one of them” situation, just pick one and move forward. Don’t get wrapped around the axle about it.
In this specific case, I would absolutely deliver the “pick the object” screen first. Not because I would be violating the “value” constraint (1), but because there is value in building the screen and getting feedback from users about it. Maybe you hide the screen in what you release to all customers (if you’re pushing the sprint “live”), or maybe you disable the button with a “coming soon” or a link to a blog post where you talk about the feature under development – whatever. The key thing is to get that (first) version of the “pick the object” screen in front of some users (or stakeholders – like getting a heuristic analysis from your UEX folks) and get feedback on it.
“Customer solves problem (that has value)” is not the _only_ source of value for what you build. “Feedback on the implementation” is valuable, risk-mitigation is valuable, fixing broken windows in your code is valuable.
With a less-narrow definition of value, this example is not really a conundrum as you positioned it. In the general case, just pick the constraint that it makes sense to violate, each time it comes up.
Hi Scott, and thanks for your suggestion. That’s very valuable.
In our particular case, this is what we did finally. It allowed to spend more time getting feedback efficiently, and finalizing this piece of work with a good quality. I’ll try to do it more and more in the future. After all, MINIMIZE BATCH SIZE!
I realized something with this post. Finally, there are few spaces where such very simple questions are asked, and it lead to a very interesting discussion. I wouldn’t have thought that in the first place. I consider this as another illustration of the discussion. From a small and simple question, I got some good feedback to move forward.
Thanks guys.
Another possibility – that I often use in your case – is to separate buisness logic from screens logic.
Usually, stories are too complicated because I want a nice functionnality with a nice UI. Is it possible to implement your story with a minimal UI ? If it is, it you could improve the UI afterward, in a second user story.
Thx, excellent point. I also try to apply as often as I can (which still lead to a huge story in this case). In the same category, you can also manage errors roughly in the first place, manage only one user profile… I was trying to come to such a solution first, in the spirit of iterative vs incremental: getting a simple but end-to-end feature, which actually allows to deliver business value.
I had never heard of separating business logic from screen logic in this case. Nice punch line, I could use it in the future.
Antione,
Have you taken a look at Richard Lawrence’s story splitting patterns?
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
I’m very experienced with User Stories, and it is very difficult to do story splitting over the internet via prose. It comes down to two challenges that create a catch-22.
1) One challenge is being able to give enough context around the story to allow readers to then suggest the optimum split.
2) If one gives too much context, one might be violating a non-disclosure agreement or other company confidentiality policies.
The best way I’ve seen to get around this is to create a fictional story with the same traits. Then, readers suggest optimum splits, then you apply the optimum split via analogy between the the fictional story and the real story.
I, too, have come across your problem before, and I would encourage you to always focus on providing some small amount of true business value. (i.e. I don’t recommend you redefine value if there is any feasible way to provide true business value instead).
My questions, to tease out your context, would be:
1. Does the first screen exist in any way in the app yet?
2. What purpose does selecting and moving the object from one place to another serve? Where does that gesture participate in the workflow and user value chain?
3. Have you tried a small thin vertical slice, implementing a tiny part of the UI for the screen?
4. What are the biggest challenges to you finishing this in the timebox (or right size target)? External dependencies? New to technology? Other?
Hi Charles. And thanks for this feedback. I didn’t know this link, it’s now in my bookmarks.
I encountered this situation quite a while ago now, so I’ll try to remember as much as I can. None of the screens (listing, selection, how to use the selected object) existed. And we knew they would each take too much effort to implement within a reasonable time. What I would probably do today is simplify the UI as a 1st step that would embrace the whole workflow, and then enrich the possibilities of the user. But If I remember well, we re-used parts of the existing UI. And it wasn’t easy to make them more generic and re-use them. And fitting this workflow in our business logic was quite challenging and needed a lot of rework as well. Anyway, I know we tried to do what you suggest, but we couldn’t.
We could also have separated the implementation of the UI (to get an interactive prototype) before plugging it into the business logic. But by experience, we miss too many issues when we do so.
What we did finally is separating steps of the workflow. It didn’t bring business value as such, but still helped a lot. It mitigated risks by discussing on the UI of the 1st step earlier (than if we had waited for the whole workflow to be implemented). I don’t think that’s what you consider as a vertical slice 😉
Antoine,
Work flow stories can be hard to split, especially when you are doing green field development or pieces of an app. Sounds like you kind of hit an anomaly there, and I don’t think there are great answers there. One answer is to lengthen your sprint, another is to slice thin vertically. Another is to realize that you’re dealing with new ground and while you may not deliver “user value”, you can deliver “business value” in the mean time. For instance, I think there is business value in delivering the first screen that gives you the list, even if the user can’t do much with the list. It may take another sprint or two to get to “user value”, which is one of the reasons that the PO in Scrum makes the business decision on when is a good time to actually release the software.
One other very important piece of context that you mentioned in another discussion on this site is that you may be dealing with an early version of a product. This also can make splitting harder, but when you’re doing an early version of a product, “business value” takes on another meaning. I would highly encourage you to look at the “Visioning” chapters/info in Roman Pichler’s book:
http://amzn.com/0321605780
He prob has some good stuff on his web site/blog about this too:
http://www.romanpichler.com/