Our product backlog wall
The ones following this blog, or the one by Rob van Lanen, probably know by now that we go pretty extreme when it comes to Visual Management. This article is like a mid-term review on our journey to visualize product development and our efforts to get colleagues and customers involved.
My first product backlog
We’ve started using scrum at our company about half a year ago and since then I’ve been struggling to optimize the use of the product backlog. My first backlog contained all wishes, ideas, requests from customers, features for the next release and so on. It ended up to be an Excel sheet containing just about everything we could possibly think of. Perhaps not surprising… it didn’t work. I tried to get people involved, but I usually lost them about 30 seconds after I pulled out my Excel sheet.
My first product board
In order to get the development team involved, I transformed one of our whiteboards into a “product board”. I had created user stories for all the features we were building and to give the team guidance I had created workflows and our UX-guy had made wireframes. I started putting the workflows and the wireframes on the whiteboard and called it “my product board” hoping the team would be immensely excited. Needless to say they didn’t use the board… they used the workflows and the wireframes, but they never got back on the board.
Time for a different approach
So let’s sum this up: my product backlog is not working and what I thought to be a great idea for the team is not beneficial . Hmm… maybe this is not the way to go.
I didn’t mention this before, but we actually work on two products with one team and our backlog was a huge (and chaotic) mixture of features for both products. In working with the team and the stakeholders I found that there were three stages any idea or feature needs to go through. First of all there is a collection of ideas (or wishes) that have not been decided on. They do not directly impact the development team but are hugely important to my stakeholders because they need to be prioritized. Second there are a couple of features that are currently being prepared so they can be picked up by the development team. At the end of the funnel there are the specific user stories that the team is building for the next release.
Our product backlog wall 2.0
I’ve transformed these observations into my new product backlog and I must say it starts paying off. The new product backlog consists of three explicit sections each targeting their own stage.
Stage 1: long term ideas and wishes
Whenever I talk to stakeholders (or customers) about future development I’m using the left side of the board (or the digital version I keep in Excel). At the left lower corner I’ve put our four core values for product development (see previous article), at the left upper corner there is a component diagram I would like to elaborate on in a future article. The right side of this board is reserved for ideas and requests. The ideas section may contain all wishes and ideas but in order to keep the list small I have grooming sessions with stakeholders and customers on a regular basis. The request section is used to register change requests. We don’t want these requests to get lost among a list of wishes. At this stage I’m treating our two products as if they were one product, only visualizing the specific product by using different colors of sticky notes. Once a month I organize a stakeholder meeting in order to determine what features, wishes or requests should proceed to the second stage in our development funnel.
Stage 2: investigate and get ready for the team
Once we’ve decided what features we’d like to work on, they go into the next section of our product backlog wall. During the second stage (blue section in the picture above) we use a kanban-like method to make a feature ready to be build. Every feature is investigated and during this process the functionality is split up to user stories and wireframes so they can be discussed by the team, stakeholders and customers. After breaking down features to user stories their relative size is estimated by the team during a planning poker session. Once the team has estimated the size of the user stories they are put on hold in the column “ready for team”. By now I need to get the stakeholders together again to decide what work will be picked up in the next release.
Stage 3: release planning
At this stage we no longer treat the two products as one product. Both products each have their own release. This last part of the product wall is used to visualize the work we’re currently doing on each of the products to get to the next release.
Major decision points
Using this product wall has helped me to visualize the work we’re doing and it had a unexpected side effect. When looking at the wall it was suddenly clear that we have two major decision points: one going into the blue section and one coming out of the blue section.
What happened to the wireframes and workflows?
Maybe you’re asking what happened to the wireframes and the workflows I had previously put on the wall. We’re still using them but we no longer put them on a wall. We’ve put them in a paper tray near the developers and guess what… they put them back after they use them.
Thanks to…
The inspiration for this product backlog wall has come from the book of Roman Pichler and his blogpost about the product backlog board.
Note at the end
Needless to say we’ve only recently started using this product wall but I must say I’m pretty confident that we’re on the right track now. And by the way… I’m also keeping a copy of everything on the wall in Excel, maybe some would argue that’s not very useful but let’s say I can’t help myself. Come to think of it: I guess this pretty much qualifies as “agile learning”.
One last thing: my goal with this blog is to share and learn so if you have any insight to share, please don’t hesitate to use the comments section.
Want to share this article? Please refer to it with the bitly http://bit.ly/eUoc26 link.
Recommended: click here for the related video blog.
Other articles:
I’m sharing to learn so feel free to comment on this article!
