I was in a client meeting  for presenting the new states of Product Backlog Items (PBIs) in Microsoft TFS. When I received the invitation for the meeting, I was excited and curious . Excited because the team I was working with, finally had enough with the pre-built states. Curious because – why is there only one team involved?

The guy who facilitated the discussion was a product owner, who looked like he was mandating the new states, and was quite surprised he was getting into an actual discussion.

At the beginning of the presentation he described that TFS is the tool product owners use to track PBIs, and it’s not just an R&D tool, so he describe the states that were important to him – writing the PBIs  and approving them (in the beginning) and reviewing the demoed PBI at the end.

The presentation at this point turned into a discussion. For example, he didn’t start from the life cycle, but started from what’s important to him. I drew the actual lifecycle and we started matching PBI states names to the life cycle states. He was surprised that a) “Done” in this team was most of the time “Deployed in production”, unlike his regular team and b) there was a life cycle state his team didn’t go through, but this team (and at least two more) did.

He tried to push for the suggested names because that’s what he used in a former workplace, and that if Microsoft is suggest these state names, we should use them (he should have ducked at this point).

The short story is that the team basically got what they needed, and good for them. But that is not the point.

When we want to improve the processes, we need to look at the whole. In this case, there was a need to see the entire life cycle, not just the part we care about. Product, development and test not only use different states, but also these were different states in different teams. It requires a holistic view, not just a single person or team.  Which leads to the second point, directly from Domain Driven Design:  Ubiquitous language.

Much like in code, names are important. When we talk about state and transitions, we should have an understanding what they mean. The fact that Microsoft suggests these names, and pushes a tool with those is something that shouldn’t even come into play. The real question is does everyone understand what “Done” really means?

I’m think that this team (and I think 2 others I work with) will like the new setup better. But it is clear that not all teams work the same, and the meaning of names will be understood differently.

Remember my surprise when only one team was invited? While I think it was a great improvement in process clarity, I’m sure it will create the same ripples when it reaches the teams that were not there. They will now see a lot more states then they knew before. Kanban talks about making policies explicit, and we exposed a whole lot of implicit ones. But not everyone was part of the discussion, which was poor planning.

I think that after the initial confusion, people will understand, and start questioning the process more, maybe improving it.

Because, like Laurie Anderson said: language is a virus.