"What's an Epic?" I hear you ask. It's certainly something I asked when I first began using the excellent Yodiz Agile Management tool where all of a sudden "Assign to an Epic" was an option in a drop down list in the Add User Story in the Backlog screen.
Epics certainly didn't make any appearance when I did my certified Scrum product owner course, and I lasted almost eighteen months as a product owner on Scrum based Agile software development projects before the word even came into my consciousness. Some of them were even successful projects!
Like everyone who doesn't know what something is these days, I Googled it. Strangely the usually trusty search engine didn't return an overwhelming volume of results and clicking on a few of the top links seemed to suggest an Epic was a User Story gleaned from a client's idea. That didn't sound right to me. Don't most user stories emanate from a client's idea at some point (unless you're working for a true "bleeding edge" start up developing something properly innovative and unheard of)?
Anyway, I left it for a while, after all, it was an optional parameter for Yodiz user stories.
Then I came across an excellent blog by a product management guru called Roman Pichler, who I find is one of the few experts who can concisely and comprehensively explain the role of Scrum and its role in improving traditional product management through agility.
The site can be found here by the way. Have a read it's worth it:
One of Roman's posts finally gave me the explanation I was looking for. Roman suggests that an Epic is a "big, [set of] coarse-grained user stories". An Epic is a way of recording a major piece of functionality, something too complex to be a user story or to be completed in a single (or small number of) sprints.
We can therefore use Epics to capture the broader product (or module) functionality at a higher level, without the complex detail that will come later in the user stories and scenarios.
An Epic also allows early feedback from users (and clients) so that you can refine the overall functionality, rather than focussing on the detail of how a particular user scenario is to be realised as a set of user stories.
To document an Epic you can use various methods. I often use diagrams on a big sheet of A3 or A2 paper (or white board) in the form of a "rich picture". A rich picture is basically a sketch full of images, flow lines and words that describes some functionality and how it all hangs together. Remember to leave out the detail - this will come later.
Others, including Roman, just use short passages of text to tell the story of an Epic. As always with agile development use what you're comfortable with as long as it works for you and the rest of the team.
The stars of an Epic are the "persona" of which there can be one or several. Give the persona names to make the story more personal and realistic - references to John, Mary or whoever, all bring the epic to life.
Describe in words or pictures what the persona is trying to do - "Mary wants to capture her heart rate and receive feedback on whether she should be worried" or "As Mary I want to easily capture my heart rate wherever I am and compare it against my target heart rate" for example. Or you could go even higher in your viewing helicopter - even more "epic" - and say something like "As Mary I can monitor my heart rate wherever I am and at anytime and check my progress over time against targets set for me by my doctor and receive ideas for relaxing and bringing it down if it's too high".
Remember to keep it simple. Don't put in the acceptance criteria you'd usually find in a User Story here, these details can be formulated later.
Roman's blog goes deeper than my post here as he expertly guides us in turning Epics into Ready Stories (which will become your User Stories). Take a look at his blog (the link is above).
Tools like Yodiz then let you link User Stories to your Epics, so you can see which stories will deliver the functionality described in that Epic. There, I knew there was a reason for that drop down menu!
For me, I now better understand what an Epic is. I've actually been using them all along - those multitude of drawings and ideas in my A4 sketch pad are epics. I just didn't know what they actually were and so wasn't sharing with the team or my users. I didn't involve them until the user stories were ready, and that is often too late. Now, I get feedback on the Epics at an early stage, which really does speed up the process and helps avoid any misunderstanding about what's required.
Epics certainly didn't make any appearance when I did my certified Scrum product owner course, and I lasted almost eighteen months as a product owner on Scrum based Agile software development projects before the word even came into my consciousness. Some of them were even successful projects!
Like everyone who doesn't know what something is these days, I Googled it. Strangely the usually trusty search engine didn't return an overwhelming volume of results and clicking on a few of the top links seemed to suggest an Epic was a User Story gleaned from a client's idea. That didn't sound right to me. Don't most user stories emanate from a client's idea at some point (unless you're working for a true "bleeding edge" start up developing something properly innovative and unheard of)?
Anyway, I left it for a while, after all, it was an optional parameter for Yodiz user stories.
Then I came across an excellent blog by a product management guru called Roman Pichler, who I find is one of the few experts who can concisely and comprehensively explain the role of Scrum and its role in improving traditional product management through agility.
The site can be found here by the way. Have a read it's worth it:
One of Roman's posts finally gave me the explanation I was looking for. Roman suggests that an Epic is a "big, [set of] coarse-grained user stories". An Epic is a way of recording a major piece of functionality, something too complex to be a user story or to be completed in a single (or small number of) sprints.
We can therefore use Epics to capture the broader product (or module) functionality at a higher level, without the complex detail that will come later in the user stories and scenarios.
An Epic also allows early feedback from users (and clients) so that you can refine the overall functionality, rather than focussing on the detail of how a particular user scenario is to be realised as a set of user stories.
To document an Epic you can use various methods. I often use diagrams on a big sheet of A3 or A2 paper (or white board) in the form of a "rich picture". A rich picture is basically a sketch full of images, flow lines and words that describes some functionality and how it all hangs together. Remember to leave out the detail - this will come later.
Others, including Roman, just use short passages of text to tell the story of an Epic. As always with agile development use what you're comfortable with as long as it works for you and the rest of the team.
The stars of an Epic are the "persona" of which there can be one or several. Give the persona names to make the story more personal and realistic - references to John, Mary or whoever, all bring the epic to life.
Describe in words or pictures what the persona is trying to do - "Mary wants to capture her heart rate and receive feedback on whether she should be worried" or "As Mary I want to easily capture my heart rate wherever I am and compare it against my target heart rate" for example. Or you could go even higher in your viewing helicopter - even more "epic" - and say something like "As Mary I can monitor my heart rate wherever I am and at anytime and check my progress over time against targets set for me by my doctor and receive ideas for relaxing and bringing it down if it's too high".
Remember to keep it simple. Don't put in the acceptance criteria you'd usually find in a User Story here, these details can be formulated later.
Roman's blog goes deeper than my post here as he expertly guides us in turning Epics into Ready Stories (which will become your User Stories). Take a look at his blog (the link is above).
Tools like Yodiz then let you link User Stories to your Epics, so you can see which stories will deliver the functionality described in that Epic. There, I knew there was a reason for that drop down menu!
For me, I now better understand what an Epic is. I've actually been using them all along - those multitude of drawings and ideas in my A4 sketch pad are epics. I just didn't know what they actually were and so wasn't sharing with the team or my users. I didn't involve them until the user stories were ready, and that is often too late. Now, I get feedback on the Epics at an early stage, which really does speed up the process and helps avoid any misunderstanding about what's required.
Comments