Five Things to Do Before Accepting an Epic or Story Into Your Agile Sprint

When using an Agile development cycle to launch a new product or platform, or to enhance an existing one, organizations do a great job of ideating and creating new Epics and User Stories, but not always properly vetting whether an Epic should be accepted into a quarterly release plan or sprint.

Here are five things to consider before committing to an Epic.

Have You Clearly Defined and Communicated the Short and Long Term Business Value?

Every Epic must have some sort of measurable business value tied to it. This could be a revenue goal, a CSAT goal, a cost of maintenance goal. If it doesn’t have a clearly defined goal, it’s not something on which you should spend valuable resources just yet. 

Here’s a great way that Object Edge Senior MACH Architect Rajiv Ramachandran likes to see teams define business value:

1. Clearly state what the feature is
2. Clearly state why this feature is better than what you have today
3. Clearly state what the desired response from the user will be. For example, “Wow, feature X has saved me 2 hours every day!”
4. Clearly state how you will quantitatively measure the business value

Have All the Lines of Business that will be Impacted by this Epic Contributed to its Goal and Definition?

Often, especially in mature products, Product Owners fall into the trap of representing various lines of businesses without actually meeting with or discussing a feature with the corresponding stakeholders or operations teams. This is a very expensive trap to fall into. 

Without input from the actual stakeholders that features are meant to benefit, countless man hours are spent developing features that are never used. Worse, it’s not even recognized that they are never used, because the stakeholders were never given an opportunity to present how to quantitatively measure whether the feature ever brought value.

Have All the Lines of Business that will be Impacted by this Epic Clearly Understood the Impacts to their Current Processes?

Referred to as Change Management, or the process of understanding how business processes will change based on new features, this is an important step to execute before an Epic goes into a sprint plan. 

In order to realize the desired value of an Epic, stakeholders need to be given the opportunity to absorb the Epic into their teams and processes. Rarely does realizing the true value of an Epic not require the assistance of a process or human up-or-down-stream. Make sure stakeholders have had the opportunity to judge how their organizations may need to change due to a new set of features.

Have the Key Architects Determined Whether the Data in Your Organization is Ready to Support a New Epic?

Almost all new product features will require data for it to function. One of the biggest challenges in executing sprints is ensuring that the right data is available and exposed within an organization.  

On more challenging projects, for example where product catalogs are involved, ensuring that product data governance is correct will impact the speed with which Epics that deal with product data can be developed, tested and released. Make sure architects have at least at a high-level validated that the right data models and services are available for a given Epic.

Have You Clearly Accounted for the Velocity of Your Teams?

While teams will self-organize during sprint planning, in most large organizations, quarterly and yearly commitments are made outside of sprint planning. As business teams and IT negotiate on what will be possible in a given quarter, ensure that you’ve properly accounted for not only the velocity, or capacity, of your development teams, but whether you have the right type of capacity.  

For example, if you accept a lot of frontend heavy sprints into a quarterly plan, but you have a lot of backend developers, even if your pointing was accurate, your teams won’t be able to produce at the velocity that was assumed. Ensure that you’ve not only looked at the pointing, but the skillsets of your teams when accepting Epics.

In Conclusion

Agile User Stories and Epics are incredibly powerful tools. Yet not every Epic makes sense to incorporate into your Agile Sprint.

These five key questions will ensure successful sprints by assessing internal alignment, input, and understanding; proper data governance; and appropriate capacity.

Still not sure where to begin? Contact the team of experts at Object Edge.