Get certified - Transform your world of work today


Delivering Epics

19 August 2013

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:
  1. Checkout
  2. Development
  3. Test case creation
  4. Exploratory testing
  5. Some other activities, depending on how team is doing things
  6. 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.6 (5 ratings)


Glen Wang, CSM, 8/19/2013 10:56:22 PM
story size is an art.
Amy Lightholder, CSM,CSPO, 8/20/2013 1:01:23 PM
Well, I'm not sure how successful a SM is likely to be convincing a PO that they are wrong when they are right. Sometimes epics really are an all-or-nothing thing.

Case in point: The epic is defined as "Opening our first store in Japan". There is no value in opening part of a store. You can limit the scope of the store, but either you'll be successful in opening a new store or you won't.

The role of Scrum in such cases is the measurement of progress and risk. You should definitely, even (perhaps especially) break an epic down into stories and sprints when it's an all-or-nothing proposition, because you need to know at what point it makes sense to abandon the epic. This is a larger version of the Scrum principle of abandoning an 'invalid' sprint, and serves the same purpose.

The rest of the message is spot-on. Even in the case of the store, many of the smaller stories will have value that can be leveraged by the business, so that even in a worst-case scenario, the sunk value is not totally lost.
Arpit Gautam, CSM, 8/21/2013 11:12:12 AM
PO is not always the alone culprit in such cases. If team breaks a bigger cake (epic) into pieces (stories) and the only way to make the cake back is to have all the pieces, then PO is not at fault at all. Team needs to make sure that every piece (user story) is a smaller and complete cake!!
Having said that I firmly believe that team and PO needs to break epic into user stories in such a way that each of these contain business value, a small chunk but complete on its own. That's the only way to build a product incrementally. There are cases I witnessed when product owner observed after a particular sprint that he/she is confident that release should happen as 40% of initial requirements are fulfilled and these are now looking promising for ROI.
Also, when PO writes an epic initially, it does look like an all or nothing proposition. It’s only when team digs deep and breaks the epic into user stories, everyone can really see what is to be exactly build and how much value each piece contains.
Lastly, I firmly believe that epics are NOT an all or nothing propositions, epics sure look like that when conceived but once groomed; high risk and low value stories can be easily identified and pushed down the backlog where they may never be implemented throughout the life of product.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up