Epic sizing and measurement metrics
Hi All,
I am relatively new to Agile. We have epics defined in Jira and user stories linked to those Epics.
Before we start measuring progress of Epics, what are the basics we need to follow to create measurable Epic.
For example, we do not have story points estimate in the epics and it is not time boxed.
Why not start with a story map, and a walking skeleton of the valuable features that might be incrementally delivered?
This might help you see the relationship between an epics and stories. Consider the literary definitions. Star Wars is an epic. Within the Star Wars epic there are many mechanism for telling the story (movies, books, TV shows, animated shows, etc). Each of these mechanisms can contain more than one story line and those story lines can span multiple occurances of mechanisms. Each of the mechanisms for telling the story require different amounts of work to produce. The total effort to produce the Epic is made up of the sum of all the story mechanisms. An Epic can live on for ever or could be completed. But how long it takes for the completion or even if it will ever be completed is not known and is determined after the work to tell the story begins.
So, given that description can you arrive at a reasonable answer to your own questions?
Hi @Ian, @Daniel, I have been reading your comments and inputs regularly and it has been of great help for a beginner like me. Found this thread searching about Epics & story points :)
Though there is no reference to Epic and Story point in Scrum Guide , It's commonly used in Agile world. I if relate 1 Product Backlog item to 1 story point than how about Epic ? How Epic can be tracked and assessed after end of every sprint to gauge the progress toward completing projected work by the desired time for the goal ?
Appreciate your advise.
A small correction in my post "If I if relate 1 Product Backlog item to 1 User story "
Hi Mohamed,
You have your Product Backlog and if you have the Epic for each Item in your Product Backlog, you should be able to see the done and open Items per Epic. By that you can tell how much has been done by now and how much is currently still to come.
But you can never give a 100% outlook for the future, as you cannot foresee if your stakeholders will brign up new ideas in the upcoming Sprint Review.
Sometimes this can be hard for customers, but they have to understand that if they want us to work agile, we cannot plan and estimate on the point over the course of many Sprints, as following any agile approach, we always show them what has been done and are responsive to change. But changes may impact schedule and budget.
@Mohamed Riaz Ibrahim, thank you for the comment. I post here mostly for my own growth because getting feedback from others on my views helps me grow. Knowing that I have said something that has helped you makes me feel good. And now on to the questions.
@Tim Moeker's answer is very good. It isn't possible to accurately predict the future but it is possible to understand the past. So for some Epics you may never be able to say when it is going to be finished while others will have a more definitive ending. When a company practices agile methods, the intention should be to react to changes as quickly and effectively as possible, not necessarily to predict future outcomes. Having said that it is not impossible or wrong to provide forecasts of future outcomes but those have to be based upon past performance. For example, there are a set of tools created by Daniel Vacanti called ActionableAgile Analytics. These tools help teams to understand their workflows. They enable teams to become consistent in workflow, cycle time and throughput. Then using that consistency, you can forecast possible future deliveries. He has written a couple of books that explain the theory and his company has provided a set of tools that can be used. I have used them with good success.
Though there is no reference to Epic and Story point in Scrum Guide , It's commonly used in Agile world. I if relate 1 Product Backlog item to 1 story point than how about Epic ? How Epic can be tracked and assessed after end of every sprint to gauge the progress toward completing projected work by the desired time for the goal ?
Epic completions are tracked by the completion of the supporting Stories because each story defines a part of the epic and is indicative of the work that needs to be done in order to satisfy the Epic. A lot of the ability to track the completion of an Epic is determined by how the Epic is stated/used. I have worked with some teams that will use an Epic to describe a product goal such as "increase number of active users to an average of 30,000 per day". I have seen others use Epics to define a new feature suchh as "Users need the ability to export their data into a customizable csv format so that they can import that data into tax software at the end of their fiscal year". Both examples have their own unique characteristics but the second is more likely to be clearly defined by the stories contained within. The first example will be a series of trials to determine how and what can achieve that goal.
I hope this helps you to understand that there is no simple answer or formula that we could give to answer your questions.
How Epic can be tracked and assessed after end of every sprint to gauge the progress toward completing projected work by the desired time for the goal ?
Might the completion of that epic accomplish some other longer-term goal? Could progress towards such strategic goals be planned, visualized, and tracked using the Product Backlog, and perhaps considered in each Sprint Review?
In addition to what Ian is mentioning, it might prove more effective to inspect progress towards the vision/desired effect of the product instead of project work. EBM just might be the things pointing you in the direction that you want here.
Thank you @Tim, @Daniel,@Ian,@Sander for valuable inputs, Similar threads really helps in understanding topics aligned with core concept of scrum/agile without any deviation.