Currently, my effort has a few Epics in flight. One of the Epic's is servicing or enhancing a product in production. We are starting to use the request feature in VersionOne to intake these enhancements/requests which come in fits and starts. Most of these requests seem to consist of Business Requirements changes, some of which were found via defects. How can we manage our business requirement change requests (mostly smaller than an feature or Epic) to a product in production, without having a representative Epic that lives forever, while still angling new stories or features to a business value?
2 Answers
Move away from Epics and trying to deliver the whole. There is always a PBI from an EPIC that is not as important as other PBIs in other Epics.
So try to change your colleagues' mindsets to focus on delivering the PBIs (user stories) and not focused on Epics.
If you find something as a result of a defect, it is a sign that something is not working properly, you need to look back into your process and see why you missed that.
Business requirements changes found via defects? This sounds like that PO's requirement are off course from the customers expectations. Agile is all about empirical feedback, so if your customer is telling you that there is a defect in the system, you make that a new user story and get the PO to prioritize it for the next sprint. If you add this to an epics then keep the epic focused.
Epic 5: Fix product's feature XXX is a better option than. Epic 5: General placeholder for all defects. Which will never close.
There are a number of other grouping options available as well, if you want to remain to have a general enhancement bucket.
i.e.
Epic: Servicing or enhancing a product in production
Can become
Epic: 2017 Q1 Servicing or enhancing a product in production
Epic: 2017 Q2 Servicing or enhancing a product in production
Epic: 2017 Q3 Servicing or enhancing a product in production
Epic: 2017 Q4 Servicing or enhancing a product in production
Hope this helps ...
