Delivering Epics

08/19/2013 by Arpit Gautam

Scrum revolutionized software product creation by promoting delivery of user stories after every sprint. However, as a product developer and ScrumMaster, you will eventually encounter those product owners who believe that the epics they initially created carry value as a whole. They will tell you that the epic will be treated as "done" or "not done." For them, the complete epic is acceptable, but it will be of no value for them to have it in partial form. They will tell you that a story breakdown is great if it's working for the team, but they want you to deliver epics, not stories, for a release.

If and when you encounter such a product owner, you ought to give him or her Scrum 101. You must tell him that he is getting it all wrong. Epics cannot and should not be delivered. Small user stories and story breakup are among the biggest strengths of Scrum, and Scrum is all about finding and eliminating waste from your requirements. You need to remind him that 80 percent of value is derived by 20 percent of the requirements, and, by that rule, breaking up of stories is inevitable for business success. After few valid data points, I think he should get the point. But if he does not, please read on.

In case you are forced to commit the epic for release and you need to now find a way to deliver it completely, one approach (which worked in such a case for me) is taking an alternate look at your user stories. From this point of view, a user story has turnaround time, and every user story has certain states associated with it. For example, a typical user story will go through:

Checkout

Development

Test case creation

Exploratory testing

Some other activities, depending on how team is doing things

Check-in

As shown, there are certain activities that we do for every story, and that take time. This time is justified and must be given, as it allows you to add smaller, more manageable increment to the product. But remember, here we are stuck with someone who doesn't want to have smaller increments. So, in our case, we decided to think about it some more.

Let’s say the effort that goes into delivery of a story (S1) is of two types:

Type 1 - Let’s call it C. This part will remain constant no matter how granular your stories are. So if tomorrow you decide to break S1 into:
S1 = s1 + s2
this effort will become:
C = c1 + c2
where c1, c2 would be type 1 effort that will go into delivering s1, s2 respectively.

Type 2 - Let’s call it X. This effort increases linearly with number of stories you have. So if tomorrow you decide to break S1 into:
S1 = s1 + s2
X will be broken down into x1+ x2.
x1, x2 is Type 2 effort for s1, s2 respectively, and x1 = x2 = X.
Effectively, then, X has become 2X because of story breakdown.

Now, first of all you must identify this and try to minimize it as much as you can. Use automation, alternative tools, and better bonding with teammates. In short, use each and every means under the sun to minimize this X.

Secondly, in cases when you are stormed into epic deliveries:

Try to make your stories bigger than usual.

Make sprints a little longer -- probably three weeks or so.

Create evenly sized stories such that you deliver one story, or two at the maximum, after every sprint.

It is worth mentioning once again what you and the product owner are going to lose.

Bigger stories are tough to size, tough to think about, and tough to write, so it will be a far more difficult job for you and your team to begin with. (That’s the reason we prefer smaller stories, isn't it!)

After one sprint the product owner can't claim a smaller increment of the product, as increments are now much bigger and may be a little incomplete (he wanted epics on release, not individual stories, remember). Probably you would have delivered more by using smaller stories if you had been allowed to do so. But now you'll complete one bigger piece, and you may be in the middle of half of a second piece, upon sprint completion. As you have committed only one story for this sprint and the product owner is not interested in stories, you should be fine.

Bug fixes will be more demanding, as now you are working on bigger parts. So bugs per story may increase. However, because you reduced the number of stories overall, the effect should be somewhat mitigated on this front, though it will be visible.

So by increasing the size of our stories, we are effectively trying to minimize the X part we identified earlier. In short, because of our beloved product owner, a part of the effort in delivering stories has now become cycle waste, and we are eliminating it by reducing the number of work items.

Lastly, tell your product owner in the sprint retrospective that your team and business are suffering because of one misplaced demand, and Scrum has a practice of delivering stories for a reason, even if he is not able to absorb it fully. Hopefully, by one release or two, he will agree -- and in the meanwhile, you have reduced wasted effort generated because of epic delivery demand.