0

As far as I know it's advised that a story in Scrum must be small - not longer that a few days. What work item size is appropriate in Kanban?

In particular - should we create very small issues (about an hour) and very long (e.g. "Be a mentor for our new junior developer")?

If we shouldn't create very long tasks (such as the abovementioned one) then how is the mentor supposed to present this activity during the Kanban project?

Improve this question
8
  • If you want effective flow, your work items should all be within the same order or magnitude.
    – Todd A. Jacobs ♦
    Commented Dec 19, 2019 at 17:03
  • How can I achieve that? A developer always may encouonter a lot of problems while working on a task - so we never know how much time the task will take. Is Kanban really appropriate for development teams?
    – Chris Brettini
    Commented Dec 19, 2019 at 17:06
  • 1
    @ChrisBrettini If your estimates are off by an order of magnitude, then your team needs to get better at estimating. Estimating 5 days and having it take 2 months is not okay.
    – Sarov
    Commented Dec 19, 2019 at 17:31
  • But we are not talking about the precision of estimates, are we?
    – Chris Brettini
    Commented Dec 19, 2019 at 17:43
  • @ChrisBrettini I was responding to 'we never know how much time the task will take', but my point also more or less stands in the general case - Do you really have tasks that take both 5 days and 2 months? Are you really unable to break those 2 month stories up any further?
    – Sarov
    Commented Dec 19, 2019 at 17:48

1 Answer 1

Reset to default
1

It depends

...On what your goals for using Kanban are.

What are you trying to accomplish by using a Kanban board?

Are you just needing a way to visualize your work?

Then it doesn't matter.

Are you hoping to improve your flow by limiting Work in Progress (WiP)?

Then keeping them consistent is needed or else your WiP will fluctuate. It doesn't matter if you have a WiP of 5 if what '5' means can vary wildly. The actual size won't much matter, but it's possible to make a larger task smaller by breaking it up but not vice versa, so aim for the lower end of your typical tasks.

Some other reason?

Then think it over, discuss with the team/stakeholders, and come to a decision based on your actual needs.

Many tasks I definitely can split into smaller ones. But what about the task "Be a mentor for a junior developer"?

Kanban is not designed for ongoing tasks. Things like 'fix any bugs that come up', 'ensure everything is always secure' and, in this case, 'answer any questions Alice comes up with' should not be tracked on the board.

However, things like 'Set up Alice's dev environment', 'teach Alice how we use Git', and 'go through our onboarding documentation with Alice' are fine tasks.

Improve this answer

Your Answer

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

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