As a team lead, the first time I was tasked with preparing a team-board, I set out to learn from how others had laid out theirs first. I started with a study of various layouts in our office and then searched the web for more ideas, which gave me enough information to tailor a new layout.
The motivation for writing this blog post is to share with you my current favourite team-board arrangement, which has changed a number of times since its first incarnation.
This layout seems to work well for now – until someone suggests an improvement. So please share your ideas on how this team-board can be improved.
Click on the image below to launch the team-board and explore its various parts by moving the pointer over the blue information icons.
Interesting layout and I like the way you’ve annotated it, I’ve always thought that it would be interesting to have a gallery of boards somewhere so that people can inspect each others’ designs.
My one comment, and this is more an observation that I am drawing from your design about your process is that the suggestion is that you draw your acceptance criteria up after the story / unit of work has been completed.
This is just an assumption though, either way, from my perspective I think it would be interesting to consider having the acceptance criteria move through the board. If your acceptance criteria are anything like ours, it would guarantee that you would have a potentially shippable increment each time you’d finished one.
Thanks for your comments Dan.
Actually, a common gallery is what I was hoping to find when looking for existing designs. I didn’t come across one so used Google image search, which brought together some interesting layouts.
The Acceptance Criteria are the first items that we look for when starting a new piece of work. We arrive at a set of Acceptance Criteria in collaboration with the relevant stakeholders. We then use the Acceptance Criteria to derive Acceptance Tests and Stories. So everything stems from the Acceptance Criteria.
The idea behind this particular arrangement of the Acceptance Criteria (in combination with the Checklist), is to create a gate through which only items that satisfy all relevant criteria can pass through. Creating a ‘Quality Gate’ if you like is what I feel to be a key benefit of arranging the Acceptance Criteria in such a way.
Moving the Acceptance Criteria through the board is an interesting idea too, which I would like to experiment with. Sounds like you’ve tried this approach before, what do you feel is the major benefit?
Emin,
Sorry for the delay in responding.
For me, moving the Acceptance Criteria through the board gives the stakeholder an opportunity to call for a release in instances where the cost of delay might be high or early feedback would be beneficial.
If, for example 60% of the Acceptance Criteria cover all of the main usage scenarios and the remainder the more edge cases, it may be worth soliciting early feedback from your users by deploying to either a limited audience (beta users for example). This of course assumes a couple of things, that you have a good set of tools to collect usage metrics and secondly, that your company or client are happy to release software in this manner.
What do you think, does that make sense?
Dan
twitter: @danrough
Dan, sorry for the late reply. I really like the idea of a stakeholder being able to just walk up to a team board and get a feel for the state of a project. As you’ve suggested, this can help a stakeholder make a call on whether a product is in an acceptable state for release, even if not fully complete.
So the challenge then is to make the board easily understandable by the relevant stakeholders. This can be achieved in various ways – moving the Acceptance Criteria appears to work for you.
In the above layout, the visual cue that could help a stakeholder gauge how much progress has been made is the density of Tasks in the ‘Done’ section and the number of ticked Story cards.
I agree that soliciting early feedback is a useful exercise. As part of our development process, we make a new version of our product available to our in-house domain experts for further testing whenever there is a noteworthy change. We’ve found this early feedback loop invaluable for resolving any defects before releasing to our clients.