I've taught how to use Team Foundation Server to many organizations through in person training and through Pluralsight videos. And I've always struggled with communicating the why regarding each of the fields in the work items. I'm pretty good at telling you what, but sometimes the why didn't come across effectively. I have recently realized that it is because I haven't been communicating the emotions that are required. It turns out that Agile and Scrum are very emotional and that it is through the emotions we are trying to appeal to the team.
Emotional? What are you talking about? Well, I must not be far off since the Scrum Guide was updated by it's founders Ken Schwaber and Jeff Sutherland to incorporate new Scrum Values. Oh sure, but values are not emotional ... aren't they? Isn't our belief in our values extremely emotional?
I was watching a Tony Robbins video on YouTube and I got to the point that he talks about his big planning method RPM. He describes it as not a time management system, but a way of thinking. He want's you to plan your day, your week, your life by becoming emotionally invested in it. How does he do that? Well, instead of thinking about your day in terms of to-do's, think about it in terms of outcomes and purposes, then the actions will flow. He breaks it down like this:
- Result - What is the outcome you want?
- Purpose - Why do you care about it? Why is it important?
- M - What is the map or massive action plan to achieve it?
Oh, I get it, if I have an important purpose and I'm trying to achieve a specific result, then the 20 phone calls to get it done seem like a small amount of effort to achieve the result. I'm emotionally invested and therefore happy and productive in getting it done. If I don't, I procrastinate and do a half-ass job.
So how does this apply to Agile?? Well, if you think about the system, it's the same breakdown, simply applied to a group instead of an individual.
Take the typically User Story used to define the work in an Agile process. Mike Cohn has popularized this with As a ... I want ... so that ... framework. Let's break it down.
- As a ... Define a who for the user story. This is the stakeholder that the developer is representing when they build it. With RPM it's always me, but now I'm trying to convey this need for someone else, so I need to convey this somehow.
- I want ... What is the outcome? What is it that you are trying to achieve?
- So that ... This is the purpose. This is the why in nutshell. The stakeholder is trying to convey the emotional importance to the developer.
Ok, that may work for User Stories, but we are a Scrum shop and we really just describe it as a Product Backlog Item and not as a story. In fact, we typically use a software service like Team Foundation Server. Well, it's the same thing. Let's use the PBI from TFS as an example. This is how it would map.
- Result - Acceptance Criteria provides the overall detailed result.
- Purpose - Title and Description provide this and allows the creator to describe why they want it.
- MAP - The action plan is a collection of child items, typically the tasks of a Product Backlog Item.
All of these breakdowns are simple, and if you use a tracking system like Team Foundation Server or Visual Studio Online, the other fields allow a more quantitative measure of the items. For example, the Effort and Value fields provide a measure of the Acceptance Criteria and the Purpose, respectively. Using this you can easily create a prioritized list that captures a measurable intent on each item. Very valuable to those who are actually reading this and trying to understand the importance of each item.