Description is too long, but this is a pain point. I just want to understand whether this is also practice of Agile, if yes, how to overcome some of the issues mentioned below. Thank you.
We are using agile scrum for our projects and we have 2 weeks sprints. At each sprint we are delivering "something". We have huge amount of micro services with multiple dev teams work on each. Therefore we have lot of internal integrations and dependencies when there are changes. Normally a CR getting added as an Epic, each epic can have multiple development tasks for each impacted micro service.
When it comes to sub tasks, sometimes there can be tasks which takes more than 1 sprint. Such CRs/Epics normally get delivered in the next sprint or whenever they are ready.
Assume we have following tasks. (Keep focusing on
Epic 1 - Task E1T1 --> MicroService01 -> DevTeam01 -> Estimate: 1 week - Tast E1T2 --> MicroService02 -> DevTeam02 -> Estimate: 2 weeks - Task E1T3 --> MicroService03 -> DevTeam03 -> Estimate: 2 days Epic 2 - Task E2T1 --> MicroService03 -> DevTeam03 -> Estimate: 1 day - Task E2T2 --> MicroService04 -> DevTeam04 -> Estimate: 2 weeks Epic 3 - Task E3T1 --> MicroService03 -> DevTeam03 -> Estimate: 1 day Epic 4 - Task E4T1 --> MicroService05 -> DevTeam03 -> Estimate: 1 day
Epic 1, 2, 3 and
4 are ordered by priorities. Which means
Epic 1 is the highest important one for the end users/customers.
Status at the end of the sprint,
Epic 1 - Task E1T1 --> MicroService01 -> DevTeam01 -> Estimate: 1 week - COMPLETED - Tast E1T2 --> MicroService02 -> DevTeam02 -> Estimate: 2 weeks - WIP - Task E1T3 --> MicroService03 -> DevTeam03 -> Estimate: 2 days - COMPLETED Epic 2 - Task E2T1 --> MicroService03 -> DevTeam03 -> Estimate: 1 day - COMPLETED - Task E2T2 --> MicroService04 -> DevTeam04 -> Estimate: 2 weeks - WIP Epic 3 - Task E3T1 --> MicroService03 -> DevTeam03 -> Estimate: 1 day - COMPLETED Epic 4 - Task E4T1 --> MicroService03 -> DevTeam03 -> Estimate: 1 day - COMPLETED
Epic 3, and
Epic 4 are ready to be go live, but assume
Epic 3 is kept hold due to further changes. Then the
MicroService03 should be released only with the
Epic 04 changes.
DevTeam03 can handle code branches in following ways.
- Make fully isolated feature branches -> Can release
- Make incremental development -> So the
Epic 4baseline also contains previously developed
Epic 3code changes. If this is the case, delivering only the
Epic 4changes is not possible.
Assume we go with #1 and we are in
Now it is hard to tell which features we should merge since,
- a). More new changes are there in the 2nd sprint for
DevTeam03only gets to know about
Epic 2dependency status at the end of the sprint
Lets assume that other dependencies are completed. Then the unit tests that
DevTeam03 completed in previous sprint are not valid any more due to branch merging. And also there could be code conflicts to be fixed with a thorough code review.
If we look at the estimate and draw a Gantt chart, we would easily decide the priorities of the subtasks, but it is not happening because of the task priority.
Also you can assume that there only fully isolated multiple task for
MicroService03 in the first sprint, and PO/SM may decide not to release some of the changes and/or, release completed, but low priority items first.
DevTeam03 should overcome situations like these?
I personally feel that this is a way of abusing Agile.
The Agile/Scrum I have learned is much much easier than this :(
Very much appreciated your comments.
UPDATE: Epic is a high level Story.