The “Input” column

You might have noticed an “Inputs” column on our illustrations here in the blog or by default on every board created with DevKan and wondered why we think it is necessary. Isn’t it redundant to have both a Backlog and an Inputs?

Board without Inputs

Board with Inputs

One easy argument is to think about how things are done in other Agile frameworks. Think about Scrum for instance: one Backlog roughly prioritised and a Sprint Backlog. What is the difference between the Work Items in these two buckets? Answer: the ones in the Sprint are the ones the team committed to deliver by the end of the Sprint. In other words, by entering the Sprint Backlog they crossed the line of commitment. And this is exactly what the “Inputs” column is for.

Like explained in our article on Kanban’s Daily Stand-up, the team should notice when the Inputs column has available slots when going through the board. A correctly set WIP limit ensures that empty slots are rare, so this is a signal for the Product Owner(s) to select the most relevant Work Items from the backlog, make sure it is ready (ie. “refined” and technically validated, with acceptance criteria and a clean enough description so that anyone in the team can pick it up and start working on it) and quickly fill this gap in the flow.

This process provides many benefits:

• The team has an opportunity to validate that Work Items are indeed ready;
• It gives the POs visibility over the team’s capacity;
• If a team works with multiple POs, they have to agree between them what Work Item gets the free slots. This way they make sure to always put the most urgent Work Items first;
• The team has the assurance to always have a well defined next task to pick up, and has visibility short term (Inputs) and long term (Backlog).

Finally, starting the stopwatch when work is committed rather than when it is started will give you more accurate metrics and more chances to find bottlenecks.