How we’re using ‘crimeboarding’ methods to map our development work
What is crimeboarding?
A term not often heard in relation to software development, ‘crimeboarding’ is a process we use here at Code Computerlove to map out a piece of work from a detailed, technical perspective. The concept’s based on the technique we’re all familiar with thanks to numerous crime dramas/movies: detectives laying out all their evidence, thoughts and links to do with a specific crime on a giant board. This method transfers surprisingly well to development.
When is crimeboarding most useful?
- When we have a new piece of work which needs breaking down into deliverable pieces of value and estimating (also known as user stories).
- When someone picks up a user story that is ready for development, but the user story is quite complex. In this case, crimeboarding allows the gathering of domain knowledge and lets the other members of the team put their ideas forward on how to solve the problem. Other people may be aware of pitfalls you don't know about, or they may suggest a better way of doing something.
How does crimeboarding work?
We usually start out with the user story in the middle of the board. If it helps, the current state can be drawn out; at this point, system flow diagrams can be useful for explaining how the system works now, or what the desired functionality is.
Next, we map out what changes are needed or any new functionality required. This may go down to a project or class level of description, or be as detailed as specifying the column names and types of new database tables.
If the ticket is being worked on now by the team, we may split up the work and add people's initials to the bit they are working on. If anything gets uncovered that hadn't been thought about (or estimated), that is drawn onto the crimeboard. It eventually becomes a living document of complexity and serves as proof of an estimate, or why something took a certain amount of time.
Once a section of work has been done, we tick it off as a basic progress indicator.
A crimeboarding example
In this particular example, we wanted to add some new functionality to one of our client’s websites, allowing a user to manage their email subscription preferences.
We did some analysis to help map out the required functionality in the form of a sequence diagram. The process starts with the user receiving an email, which takes them to the website; from there they can make changes to their preferences. Those changes are then saved to a database and passed on to some external email management software.
Next up we began to map out the changes required to the existing system, and any new components we would need to implement the new functionality of allowing a user to manage their email subscription preferences. We identified three user types and the different paths they would take through the system such as ‘updating’ or ‘unsubscribing’.
Then we listed the new code elements we would need such as pages or handler classes and the new tables we would need to save the data to. Finally, we logged the last parts of the journey where the data would be sent on to, all the while keeping a list of things that we needed to go away and double check.
In the final part of the crimeboarding session, we split out the work into separate user stories, and did a small estimating session using Fibonacci sizes.
Alternatives to crimeboarding
Another way to gain some of the benefits of crimeboarding is pairing (where two people work simultaneously on the same machine) or mobbing (three or more people working on the same machine).
This way, the collective knowledge is used in real time, with everyone working on the same user story at once. With the person at the keyboard concentrating on typing, the others are free to think around the problem slightly more, keeping an eye out for any issues that may arise or thinking about better approaches to the problem. Pairing and mobbing have a host of advantages which could fill many more blog posts!
As a team, though, we love the crimeboarding method – it facilitates a more team-centric approach, helps prevent silos, and promotes collective ownership of the codebase.