Essential Scrum — Delivering Value
Slicing work across Epic priority
Assume EpicA is higher priority than EpicB. Just Epic based priority won’t make sure the teams are working on the most practical high priority item. You need to slice the Epic vertically as well so that you are not working on some small featureK of EpicA which is actually less important that featureM of EpicB. Use sprint reviews and other avenues to discuss a deeper level of backlog with stakeholders to make sure the priority isn’t directed only by one time Epic level priortization that happened 3 months back.
Test things early in the release cycle.
Finding a bug 1 day before the code freeze is not helpful for anyone. However, you will find bug 1 day prior to code freeze if you were merging your code till 2 days before code freeze. Keep an internal cut-off date for merge stop and validating things reasonably earlier than the actual code freeze. This can be done by having two code freeze dates (and their two corresponding code branches) where people are allowed to merge changes to only bugs/critical misses in the second branch.
Plan for product’s Release cycle
Plan for Sprints/Months/Year but also keep a very strong eye on product’s Release cycle otherwise you and the team will find yourselves chasing the cot freeze date at the far end. Don’t delay work just because you don’t want that feature/change to reach production just yet, instead use tools like LaunchDarkly to control visibility in production. Don’t blindly follow the release fundamentals of single client SaaS products in your ecosystem if your product spans desktop, web, mobile etc. where each one will have its own release cadence and deployment process.
