How do you guys manage really short User Stories?

> We have a rotative role into our team for bug solving and urgent
> support to advanced users. This role uses a kanban queue to
> manage their tasks. Do you think it's a good idea to include those
> mini-stories into the same queue as bugs and support tasks, sharing
> the priorization scale?

It sounds like this "rotative role" has their own backlog (kanban queue) and this person is not really part of the team at all...at least not while they are occupying this role silo. It would be better to have a separate BAU Kanban team for handling small and repeatable changes such as minor enhancements and defect fixes.

Having said that, if these minor enhancements are in support of a particular Sprint Goal, then they can and should be handled by the Scrum Team during the relevant Sprint. Alignment to a Sprint Goal is the deciding factor. If the Product Owner values a PBI enough to negotiate it into a Sprint and with a view to releasing it in a particular increment, then it would be inappropriate to triage such work into a separate Kanban. A Kanban does not deliver to Sprint Goals, and follows different rules for prioritization and quality of service.

Many thanks Ian, very helpful.

Yes, there is a separate backlog -kanban queue- and those persons assuming the role are not part of the team (if we strictly talk about the scrum team) during that iteration. Do you see any big risk on maintaining this role as "rotative" instead of a dedicated permanent team? The team itself decided that the rotative approach was the best option since being the POC for immediate support is not the most appreciated task :)

I understand the point of the minor enhancements aligned with the sprint goal, that's our approach. In that case it's easy to identify any other related bigger story to merge with the minor improvement. I was referring to those cases where the improvement is not related with any sprint goal at all.

> Do you see any big risk on maintaining this role as "rotative"...

Yes, in so far as it implies that the rules of Scrum are not well understood. In Scrum a Development Team must not have sub-roles, whether rotative or not. Also, the Product Owner must be solely responsible for determining product value, yet work is finding its way into your team (via the embedded Kanban) which the PO apparently does not value enough to plan into an increment.

> ... instead of a dedicated permanent team?

A dedicated team does not have to be permanently staffed. Rotation of members between teams isn't necessarily a problem, and is something that is often done between Scrum Teams in order to help disseminate experience and knowledge. You therefore could rotate staff between the Scrum Team and a Kanban Team which is a separate entity following its own rules.

There may be another option which is to allow the Scrum team to vary its quality of service by including a "Fast Track" or "Expedite" lane on its task board. This hybrid approach is sometimes referred to as "Scrumban". Small fixes or defects, or incidents that were unforeseen in Sprint Planning, can be be triaged into this lane by an authority which is not necessarily the Product Owner. Unlike your present implementation there should be no dedicated sub-role for handling any expedited work. Instead, the team should self-organize on a case-by-case basis to decide how each fast-track item should be progressed and by whom. This isn't Scrum for a number of reasons, including the fact that the Sprint Goal could be compromised by a surfeit of unplanned expedited items that have to be worked on. Even so, many organizations find it to be a practical compromise.

Thank you Ian, I really appreciate your answers.

I see the discussion is more on how we name things rather than how we organize the work: It makes no difference for me to identify the kanban-dedicated persons as a sub-role of the scrum team than treating them as an independent kanban team, as long as we have a separate group of people dedicated to attend the kanban queue following their own rules separately from the scrum processes.

The Kanban queue is not meant to add product value at this moment. That's my biggest concern in including these mini-stories into this queue. But I see no other option without compromising the alignment of the user stories to support a common sprint goal.

> I see the discussion is more on how we name things rather than how we organize the work

In Scrum the names that are given to things are very important, because they have a precise meaning. If you've got a sub-role in a Development Team, you're not doing Scrum. It's important to be very clear about what the words used in Scrum mean, or there could be misunderstandings about how a team works and the kind of service it provides.

I agree with Ian that everything done during a Sprint should go towards the Spring goal. So it doesn't really matter if its a 20 min task. This task can still be mapped to something of value to a client and if so then a story or epic comes into the picture.

At the end of the day if you are still working on the same product then anything you do contributes to the completion of the product.

Its just a matter of organizing the work to correspond with the bigger picture