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 MicroService03
)
First Sprint
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
Assume 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
So the 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
Epic 04
easily - Make incremental development -> So the
Epic 4
baseline also contains previously developedEpic 1
,Epic 2
andEpic 3
code changes. If this is the case, delivering only theEpic 4
changes is not possible.
Assume we go with #1 and we are in Sprint 2
.
Now it is hard to tell which features we should merge since,
- a). More new changes are there in the 2nd sprint for
MicroService03
- b).
DevTeam03
only gets to know aboutEpic 1
andEpic 2
dependency 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.
How 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.
Epic 4
being work onMicroService05
made byDevTeam05
, but that epic ends up with it being work onMicroService03
made byDevTeam03
; is that a typo?