I recently shared an older post on UX work and Kanban boards.
Where Do We Put The UX Tasks?
In my career I’ve heard this conversation play out over and over:medium.comIt sparked some interesting questions and feedback.
Tl;dr … design is hard :)
It is important to step back and understand the WHY. Why do we use Kanban boards? We use Kanban boards as a catalyst for continuous improvement. Visualizing work helps us see patterns, dependencies, relationships, bottlenecks, and handoffs. A well designed board (or set of boards) is immediately understandable. It provides instant situational awareness.
When is a Kanban board a waste of time? When it never changes. When it provides no learnings. When it does not reflect reality. When people stop looking at it. When it is used to manage a team, instead of providing a way for a team to manage itself.
Visualize things as they are. Don’t cloud reality because…
- Jira limits you in how you can visualize the work
- A manager does not really understand how things work
- Someone has to manufacture a fictional velocity metric
- Someone gets nervous seeing things as they are
- Creativity is messy
- Your sprints will get “messed up” and you can’t “close them out”
- Jira only lets you assign a single person to a “ticket”
Never sacrifice an outcome to customers because “that’s how Jira works”The value of situational awareness ALWAYS outweighs those other needs. Never sacrifice an outcome to customers because “that’s how Jira works”. I cringe whenever I see a team so obsessed with velocity, “successful” sprints, and “good estimates”, that they artificially split and mangle work to keep their managers off their back.
But realize that…
- People need different bits of information at different times, and in different contexts
- Our work tends to be a mess of relationships For a board (or set of boards) to be useful, they need to match reality AND be usable in context. We tend to stray from reality in an effort to make the board useful in a specific context. At standup, for example, the team might be focused on fairly prescriptive tasks. A board that shows all the complex relationships with higher level goals will not be usable (useful).
Reality is Messy
Let’s take an example. You and I are working on something together. To finish that something, we generate a ton of experiments. Most of those experiments will fail. We also have a number of individual tasks, and some tasks we want to pair on. There are various stages of “done” ranging from low level items being completed all the way up to to our high level expected customer benefits. Some of your items depend on my items. Other people are interested in our work (marketing, other developers and UX, managers, etc.)
Our mission here is to visualize everything — all of these nuances — while at the same time making the visualization (or visualizations) useful in various contexts: daily work, retrospectives, prioritization, collaboration, testing, etc. What we tend to do, is to fold on something. We fail to acknowledge the complexity and optimize for one need (to the detriment of the others).
NO… ONLY splitting our tasks is a mistake. We need that relevant information. Our tasks, alone, are not valuable. AND, we need to know that we are pairing today, or doing our own thing.
I’d give an example, but it will give the impression that there is a right way. The right way is very, very context dependent.
This generic image might give you some ideas though … observe how we combine 1) the sense of a mission, with 2) the understanding that we are running experiments, with 3) a phase for actually measuring those experiments, with 4) an explicit phase for reviewing those learnings, and making decisions.
But note how this is incomplete, and we would likely need some additional visualizations for 1) upstream work … prioritization and decomposition, and 2) perhaps a more detailed sense of what is happening In Progress (specific tasks, etc.)
. A team working in this context might choose to have an “In Progress” board to make stand ups and daily collaboration more productive.
At least n=1, I always try to use physical boards and keep them all on a single wall. This is the failing of software tools. You tend to myopically look at one board depending on your role.
Designers deal with these challenges EVERY day. Designers are constantly solving the puzzle of utility in context. When a designer says “you can’t capture my creative process on a Kanban board” I always invite them to apply their design skills to the challenge. It isn’t that hard. Remember, even physical products with strict manufacturing “stages” have periods of messy design.
From that perspective, a Kanban board (or boards, or board and set of other visualizations) is a design challenge. To improve your board’s design ask these questions:
- Do we know where energy is being applied to things of customer value?
- Do we understand how we are collaborating? Who is working on what AND how are those individual items contributing to high level goals?
- Where are decisions being made? Where is information changing hands? How is information and energy contributing to the “value” of the item?
- Can we visualize how work is related (e.g. parent/child, high level/low level, experiments/hypothesis, etc.)
- Are we differentiating between Goals, Impact, and Deliverables? Marking a user story as complete may have no bearing on whether the impact has been generated and/or whether we have hit our business goal.
- Are we accounting for experimentation? For example, are we artificially calling experiments “done”, when in fact it is the hypothesis that matters…or even moving up a level, the customer value related to that hypothesis?
- Are people able to get the information they need, when they need it? You can have an awesome board, that is not usable for day to day work.
- Are we capturing our working agreements (e.g. does the team stop all work to handle production issues, or do small groups of people start work on items long before they are “In Progress”)
- Is the board a useful catalyst for continuous improvement?
Can you add a new team member and have them immediately understand how
Running Out of Time. In Closing
Hitting my timebox for this post!
Don’t let the tool run you. It should be YOUR tool. Expect to iterate as the nature of your work changes — and your understanding of the work — changes. Many teams feel limited by what is in their software of choice… there’s no reasons not to try 1) circular boards, 2) adjacent experiment boards, 3) adding charts for customer outcomes and learnings, and 4) when it doubt, a BIG HONKING STICKER to explain what is going on.
If it doesn’t reflect reality…change it. If reality is too scary. Well, that’s another problem altogether :)