As most practicing Agile team members have found, the real world of software development organizations come with a generous mix of work efforts.  Common for any team to see are requests for stakeholder high-value features, company-driven strategic capabilities, adjustments to features due to some change mechanism, tiny “stories” of honey-dos, the “hey, can you look into this?” tap on the shoulder, and the plentiful “Ohhhh, snap!” fix.

Sometimes the worst part is that the skills to fix these issues are on YOUR team – not a dedicated bug fix/honey-do team – and they happen on a regular enough basis to be considered just part of the team’s normal work.

To deal with these events we would normally look to our Product Backlog management process as a way to feed these needs appropriately to our Agile teams for their coordinated consumption.  But what if – as occurs with a team I am currently working with – many of these atypical user story/ feature requests are production impactful or such that other dependencies necessitate them to be worked immediately?

Gone is the idea of spending time to write the story in the proper ‘INVEST’ model, or groom and review, estimate, and prioritize before any action is taken – because you exist in an environment where negative impact to a customer cannot be tolerated.  Add to that the process of Sprint Planning and breaking the story into tasks?  No way – it’s “we need these ASAP” while you do your normal Sprint work.

Okay, we good Agile implementers can come up with a few ways to handle these one-offs or honey-dos…we do it all the time.  Here’s one I saw demonstrated with success and incorporates the use of two great Agile concepts that I’d like to share with you and hear your thoughts and ideas, too.

The tactic is to employ both a Scrum board and a Kanban board together on your team’s wall.  Here’s how that may work.  Have the product owner operate the planned Sprint forecast commitments through your normal Scrum process and board or wall.  Now, pass the ever-emerging honey-do needs through another short process of work flow control:  a) a brief discussion about the ‘story’ with the Scum Master and team either during the daily Scrum or in a separate huddle, and b) do a story point estimation on the item(s) the product owner brings.  Then place those on a Kanban portion of the team’s wall or board.

scrumban wall

v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}

Now it’s possible to track all the team’s work on one board where they can see story progress, impediment incidents, story points accumulation, burn down of tasks, the cumulative flow (if you like) and hold one common stand-up for all your work.  The team watches out for their Sprint commitment yet allows the other work to flow through the Kanban board as items are worked using that great process for this type of service request.

Your PO can maintain your priorities across all your work and the team’s velocity metrics (taken for all ‘done’ work at the iteration’s end) will now reflect the truth – how much can the team get to ‘done’ in the iteration’s time-box when considering all the types of story work that they inherit.

I’ve even see a team establish their own schedule where resources rotated each iteration to “man the Kanban work”.  I enjoyed how this technique reduced the clutter, provided great transparency and understanding of the real work asked of the team.  Many a manager changed some of their previous assumptions and expectations after seeing the team’s reality on one nice wall.