4

Our work is organized around epics, which are the unit of business decision making and prioritization. Each represents a higher-level business feature or technical task. Epics are divided into user stories and take usually 1-3 weeks to finish in a team.

Our team works in a kanban-ish process where we pull stories from the epic, mixing in bugs and sustaining tasks as needed. There are no time-boxed sprints. We follow the rule that WIP is limited to 1 epic.

The problem I've noticed is that there seems to be a lot of time wasted on the boundary between epics. Towards the end of work on an epic, we get increasingly blocked by lack of tasks we can work on or dependencies. We've tried increasing WIP to 2 epics but it didn't help much - there's still hesitation and waste before we open a new epic.

How can we improve our process to eliminate wasted time on the boundary between subsequent epics? Does limiting number or epics in progress make sense? Should we put a limit on WIP for stories only?

Improve this question
3
  • Kanban is a tool for learning and managing the optimal flow of work within a process. What I read here is some workaround which is not kanban style ...
    – Paul Willons
    Jul 19, 2016 at 23:47
  • What change do you propose?
    – Mifeet
    Jul 20, 2016 at 11:35
  • I'm not sure this answers the question.
    – MCW
    Jul 21, 2016 at 13:42

2 Answers 2

Reset to default
5

I worked with an organisation that had a similar problem (although we were using Scrum rather than Kanban). What we found was that the work became very bitty towards the end of an epic and it was often difficult to keep the team busy. The problem was made worse by the fact we had different Product Owners across different epics. So the boundary of epics became a boundary for the Product Owner as well.

The solution was simple. Stop planning around epics and instead plan at the task or story level. At this finer level of detail it is easier for the team to balance its work. For example, they would often mix the start of a new epic with the end of the previous epic. This allowed the team to be fully utilised and to transition cleanly between epics.

Improve this answer
3
  • Yeah, it's the same with us - often different POs. Thanks for the answer!
    – Mifeet
    May 19, 2016 at 12:21
  • I've proposed this to our team and they had one concern - that this will not be motivating enough to close epics in progress. Didn't you have a problem with epics not being finished for longer time?
    – Mifeet
    May 19, 2016 at 12:25
  • We were very careful to prioritise the stories within an epic, so the stories that tended to be at the end were the lowest priority ones. The team was less worried about these stories and hence were not too concerned about epics being 'unfinished'. Also, as the team were regularly demonstrating progress to the Product Owner and stakeholders they got regular feedback on how valuable the work they were doing was.
    – Barnaby Golden
    May 19, 2016 at 12:52
0

Here is another suggestion that I got at our local agile meeting.

In Kanban, the WIP limit can be defined to different columns on the Kanban board. We could introduce new column/state for epics called in deployment. An epic would pass to this state when all that's left is waiting for deployments, dependencies, or backwards compatibility removals.

This would allow us to start working on a new epic at a clearly defined point in time, when the previous epic is not finished yet, but there's no real work left. There could be two epics in progess, but at most one in development.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.