Hi Dave! Great points.

1. That would make my day! If you can get your group of UXers, dev, data scientists, researchers, etc. to view themselves as a single team I’m all for it! That is how I prefer to work when I can.

2. On the far right, I see unmet customer needs. I’m a big believer in outcomes over “just shipping”, so I agree with your point about the word shippable. This is why in the final example I have “monitoring customer outcome”. In a pull system, those unmet customer needs “pull” work from the team. I’ve always struggled with learning in this context. Learning is valuable (perhaps the MOST valuable thing we do), but unto itself it does not meet the customers need. See some of my thoughts below about the root problem here, especially the question about mapping work (it is parallel because it happens at the same time) vs. mapping value. I didn’t mean to suggest that this was the only way to map value, rather that regardless of how you map value, you’ll still have to decide on how to indicate collaboration and signal the desired (by team, hopefully) handoffs. I agree 100% that you don’t want your tool to get in the way of good work, which is why I typically suggest physical boards and the team working to make it their own (and to reflect reality). The challenges I see are as follows:

3. Scrum-myth. To your point, I feel that the Scrum rituals are very restrictive, and they force teams to create side systems to keep track of all the work “outside” the Scrum. So, for example, if a team is doing discovery work they’ll be forced to create a parallel system just to keep the illusion that Scrum works in these neat boxes. Why not get all eyes on the work — including the discovery work?

4. Team agreements. How is the team actually work? How do they want to work? What is the best way to work for the current challenge? Echoing #1, what I notice is that to preserve these neat little lines, teams adopt more hand-offs and more siloing of dev/ux/product than is optimal. Poor UX folk work their butts off in a distinct Trello board, to try to meet the org’s pressure to “land” tasks on developers. Or product has an arcane prioritization system in Google Sheets, that the engineers never see until the work materializes in the “to-do” column. Now, this may be how the team wants to work, but often it is how they think they’re being told to work, and they don’t get to reflect on whether it is working.

5. Holistic System. To #2, if the team wants to stagger discovery / development, then depict that somehow to get everyone on the same page. If they want to send a small speedboat research team out to “get ahead” of work, then depict that somehow. If they want to wait to see data demonstrating customer outcomes, then add that rightmost column. If you are deep in the discovery phase, maybe you need a validate learning board that sits alongside the “work” board.

6. The balance of mapping value vs. mapping work. Mapping work helps answer the question “what am I working on now” and “what will I work on next”. It helps the team know who is working on what. Mapping value is a bit different. “Shipping” something doesn’t make it valuable, or take it off your plate. All too often we fall back on looking solely at work, not value. This makes sense on some level — it might be our day to day concern — but it obscures the big picture. That balance between the big picture and day/to/day tasks is a big challenge. I dunno. I’m blabbing. Perhaps I misunderstood your questions. DM at @johncutlefish on Twitter.