Dealing with large tasks
I am busy researching the best methodology for managing my product and I am trying to figure out whether scrum is right for us.
One thing I didn't understand and couldn't find the answer to so far is- how do you deal with larger tasks/features? I saw that a lot of people have the same concern and the common answer I see everywhere is that I must learn to break down larger features to smaller stories.
Still, there is something I fail to understand.
I have a specific requirement, for example replacing a main component of my system to a different one. I know that this process as a whole can take 3 months. I also know that I can break it down to many smaller tasks of which each can probably fit in to a 2-4 weeks sprint, but nevertheless I read that at the end of each sprint every story is supposed to become "done" and "potentially shippable".
Now, if my large task (or "epic" as I have learned they're called) is broken into 20 smaller stories, then maybe I can truly get each story "done" within a specific sprint, but my understanding of "potentially shippable" is that the each story should also be up and running at the end of the sprint. But here is my problem- if every such story is just a part of a bigger task that can't be launched before all other parts are finished then it isn't really shippable at the end of the sprint, is it?
What am I missing or misunderstanding?
Help? Someone?
Thanks a lot.
Hi all,
I think I'm not completely through with this "contradiction", too.
I smoothed myself saying "Potentially shippable does not mean, there is really a customer out there who'd want to pay money only for getting this Increment. Potentially shippable means, there is already some value, it is self-contained and it works (as little as it may be)."
I'd be glad to hear some feedback to that.
My understanding is that "potentially shippable" means no extra work is required for the increment.
The increment is "technically" done, but maybe the increment is not functionnaly "rich" enough to be considered as a "minimum viable product" for the user.
Be aware that splitting an epic into smaller user-stories is not the same as splitting a user-story into several tasks.
User-stories have value for the user but tasks are just a mean for the dev team to decompose the work to be done and have no value for user by themselves.
Thanks for the replies. I am still having trouble understanding though.
My concern is basically dependencies- let's say I can complete a full increment, but there is no way I can release it because it depends on another increment, and I cannot complete both within the same sprint.
In such case, how can I stand up to scrum's "Done" standard?
Hi.
You basically put the finished component on the shelf. Then when you have all the components that you need on the shelf, then you would look to release all of them. So each individual components is potentially releasable.
On the other hand if your stories are too epic, maybe Scrum is not what is needed and you might need to use V-Model
Hi Stephen,
I disagree. The advantage of Scrum is not only that you could technically and theoretically ship each increment. It's also that you can quickly (inspection) see (transparency) if what you are doing actually leads to your goal. And if not you can quickly change your habits (adaptation).
This advantage doesn't disappear only because it's not sensible to sell all of the Increments.
> You basically put the finished component on the shelf.
Putting components on the shelf means having unused inventory, which is waste. Shelved work isn't providing ROI and is subject to depreciation. Moreover, it incurs the risk of missed opportunity cost because work of more timely significance wasn't actioned.
Whenever components are shelved it is important to question why this has happened no later than the next Sprint Retrospective. Having a lean value stream requires an understanding of a Minimum Viable Product and how this differs from a Minimum Marketable Feature.
@Ian, I must confess that I have difficulties to see a clear distinction between MVP and MMF.
Can you briefly explain your point of view ?
One thing you state is 'I have a specific requirement, for example replacing a main component of my system to a different one.' I would ask what the business value is behind replacing the main component? Knowing this, it may help you breakdown the story. Well, the requirement should be turned into a story first, to understand who the user of the system is and what they are trying to achieve.
An MVP can be seen as the smallest thing that generates a response, and thereby permits the inspection and adaptation of product requirements. So in Lean Startup terms (which arguably drives this definition), an MVP might be a smoke-and-mirrors prototype with no back-end behind it, and with people fulfilling transactions and supplying a response manually. Obviously that isn't marketable because it doesn't even begin to scale, but it can test an early value proposition for comparatively low cost. That's what's "lean" about it.
A Minimum Marketable Feature (or a Minimum Marketable Product) is the smallest product you can actually release that the market will bear.
In other words, the "viability" in an MVP is less about market viability and more about the viability of just getting a response and gaining traction in a validated learning cycle. At some point in that journey you would expect the *marketable* feature set to emerge.
NB the distinction between MVP and MMF isn't obvious in Scrum, because a potentially releasable increment may correlate to either one of these. In other words a PO may choose to release an increment in order to test a new value proposition (an MVP), or to gain market share (an MMF).