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:
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.