Click here to go straight to the interview
Chris Matts is an Agile though leader and coach based in the UK. He’s also co-author (along with Olav Maassen and Chris Geary) of ”Commitment: A Novel About Managing Project Risk”. What makes the book so unique is that it is a graphic novel. The purpose of the story is to help the reader gain a deeper understanding of how to make truly informed (right) decisions based on a deeper understanding of the issues they are facing.
Real Options is the central them presented in the book. This is a process that has been borrowed from the financial sector and applied to the decision making process that is part of managing project work. The Real Options approach helps provide clarity around when decisions need to be made, rather than just focusing on how they are made. It begins with three key ideas:
For more about Real Options, go here
One of the unique things Chris brings as an Agile coach is his background in investment banking. The application of tools and techniques from this area can provide a gateway or bridge into Agile for those coming from a similar work history. (Much the same way that looking at how Earned Value can be applied in Agile can help provide traditional PMs with a reference point.)
Chris is currently focusing his coaching efforts on how Agile works in the enterprise. If you’d like to learn more about the work he is doing, check out the podcast here.
Marcello Scacchetti lives, works and practices Personal Kanban in Italy. After a co-worker of mine posted on Yammer that he was using Marcello's Personal Kanban Google App, I reached out to him and he was kind enough to let me interview him about how he is using PK to manage his work and various projects.
While Marcello's approach towards Personal Kanban is a little different than my own, we have had similar learning experiences while using it. For Marcello, he says during the interview that Personal Kanban saved his life.
During the interview Marcello also talks about his use of Value Stream Mapping and how it has helped him with prioritizing the things he does (both inside and outside work). He also explains how he codes everything he does once it has been completed based on how much joy it brought him. (This is where I got the idea to do this with my own work - see the post here.) These are two of the factors that contribute to Marcello's practice of spending 80% of his time doing things that bring him as much joy as a kid feeding ducks.
I hope you will enjoy the interview. I got a number of ideas from Marcello that I applied to my Personal Kanban testing after we spoke.
Note: The link to the file has been updated. It can be found here. (3-4/13)
(This is an update to my 10/28/12 post on How to Avoid Overcommitment DuringSprint Planning. )
For awhile now I have been using an excel spreadsheet I put together to work out the calculations I detailed in the post on avoiding overcommitment. I have also been sharing it with the students in my CSM classes. I recently updated it so that the times allocated for the different Scrum meetings is in sync with the current version of the Scrum Guide and I thought it would be a good idea to post here just in case it can be of help to anyone.
In case you missed the earlier post, the intention of this calculator is to help individual team members on a Scrum Team gain a better (more true) understanding of the amount of time the can realistically commit/forecast to be able to contribute to the work the team will do during a Sprint. I have found this to be very helpful for teams who are struggling with understanding their capacity.
An example of how this could be used in s Sprint Planning is...
1. Once a Scrum Team has forecasted the amount of Story Points it can expect to get through during a given Sprint based on average historical velocity.
2. And defined tasks for all the stories.
3. And estimated the ideal engineering hours required to complete each individual task.
4. And totalled up the collective ideal engineering hours required to complete all the work they are forecasting to complete in the Sprint.
5. Each team member can use this calculator to determine how much time he/she can expect to be able to contribute in the Sprint.
6. Once each team member has come up with his/her number, you would total those up to get the total amount of ideal engineering hours the Team expects to be able to working during the Sprint.
7. If the value resulting from Step 4 is greater than the value from Step 6, then you may need to reconsider the amount of work your team is forecasting to complete in the Sprint, or modify the scope (and tasks) for one of the stories.
8. If the value resulting from Step 4 is significantly less than the value resulting from Step 6, you may need to consider adding some additional stories/work into what is being forecasted for the Sprint.
* Some teams I have worked with have taken the additional step of applying this technique by work type within a Sprint, i.e. Development, QA, UX, etc.
This work is licensed under Dave Prior is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.">Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
Awhile back I was working on an Agile coaching gig with Tom Smallwood. We were working with a team that moving to Scrum and was having a particularly difficult time meeting their commitments. Stories were being estimated in Story Points using the Fibonacci sequence and they were breaking stories down into tasks that were then estimated in ideal engineering hours. Stories were (mostly) small enough to go from card on wall to potentially shippable in about 2 days. Tasks were kept to between 4 and 12 hours. Unfortunately, despite following the basic guidelines we were giving them, they were still WAY over committing each Sprint.
Tom was the first one to notice that even though they were all confident in their ability to get the work done at the end of a Sprint Planning meeting, what they were confident about was in fact, completely impossible. What was happening was that each person was assumed to have a capacity of 8 ideal engineering hours per day. Since we were working in two-week iterations, this meant each person was on the hook for 80 hours of productive working time in a Sprint.
The way we addressed this initially was to ask them to plan for no more than 6 productive working hours per person each day. This helped, but it still wasn't cutting it. The problem was that each person had more that they were responsible for than just the project we were working on. (Yes, this is not ideal, but it was reality at the time.)
The solution we came up with was very simple and it is one I have used on every team I worked with since. It adds an extra step to the Sprint Planning ceremony, but it has been invaluable in helping teams understand their capacity and preventing over commitment.
(Disclaimer - this involves using relative Story Point Estimation for Stories and Ideal Engineering Hours for Tasks. There are many who do things differently and have great success - which is awesome... what follows is just what I have found to work well for me and the teams I've worked with.)
What we added was a step in the 2nd half of Sprint Planning. After the team has taken the User Stories (estimated in Story Points) and broken them down into Tasks (estimated in Ideal Engineering Hours), we would go around the circle and ask each team member to estimate how many ideal engineering hours he/she could commit to being responsible for in the upcoming Sprint. One of the most critical parts of this is the idea that the commitment being made is not to the PO, but to the other members of the development/engineering team. So, if I tell my team I'm good for 35 hours, then my team can count on me to be responsible for 35 hours of task work. If I commit to that and do not contribute that amount of time, my team members will have to cover for the work I've not done. While this should go without saying, I have found it to be helpful to mention when starting this part of Sprint Planning.
So, going around the circle, each team member has to be aware of how much time they can commit to contributing. This means they need to account for a lot of the things that get in their way.
Here is how I normally coach people to think through this:
In a two-week iteration, you begin with 10 working days. However, I normally block out 1 day for Sprint Planning, 1 day for the Sprint Review and Sprint Retrospective, 1/4 day for the 8 remaining days during which the team will hold a 15 minute daily standup and 1/4 day for an Estimation/Story Meeting. While blocking out 1 whole day for Sprint Planning and 1 whole day for the Sprint Review and Sprint Retrospective meetings is more than the Scrum Guide calls for, I have found that it is more realistic to working under the assumption that the team will get little else done on those days.
If the Sprint is 2 weeks long, we start with 10 working days. Once we block out the time mentioned above, we end up at 7.5 working days.
If we assume each person can be productive for a maximum of 6 hours per day, then:
6 hours/day * 7.5 days = 45
So, the absolute Maximum Possible Productive Hours (MPPH) for any individual in a two- week Sprint is 45 hours.
We then ask each person to total up the amount of time they expect to lose during the upcoming Sprint to the following events that are not part of the Scrum Framework:
* Getting pulled away from a project to deal with emergencies that are not related to the project is a dysfunction that will impair the team's ability to realize the full benefits of Scrum. However, in several organizations I have worked with, it is a constant reality. When things break, and the money stops flowing, it's all hands on deck.
The total of the above is the Interruption Time (IT) that each team member must subtract from his or her MPPH. The amount of time left is the Revised Maximum Possible Productive Hours (RMPH).
If the individual is only working on a single project, then the RMPH is the amount of time that individual should feel comfortable sharing with their team members as their Committable Productive Time (CPT).
If the individual is split on multiple projects, then they should multiply the percentage of their time that is allocated to the project by the RMPH. They should then subtract an additional 10% from the result (for context switching) to get their Committable Productive Time (CPT).
Here is an example of the above...
Interruption Time (IT) = 25 hours
- 25 (IT)
If I am split across 2 projects at 50% each...
-10% (context switching)
9 hours of Committable Productive Time
In talking through this, it is very common to see jaws drop. However, if each person on the team is doing this, then the team will have a realistic understanding of its' work capacity in a given Sprint. While the idea of having to tell someone responsible for your performance review that in a two-week period that you can only be counted on for 9 hours of time may be scary, it is honest. If we are practicing Scrum and sticking with transparency (one of the 3 legs of Scrum), and we are being responsible to our fellow team members, this is the most responsible, transparent thing we can do.
Once each team member has shared their CPT, they are totaled up and this is the Team's Committable Productive Time (TCPT). As long as the total number of estimated ideal task hours does not exceed the TCPT, then the team should feel comfortable making a commitment to the Product Owner for the Stories they will complete during the Sprint. If the number of estimated ideal task hours does exceed the TCPT, then the team may have to negotiate with the Product Owner to reduce the work being planned for the Sprint before they make a commitment.
I have also seen teams break things down even further into number of hours for development, testing, etc., but what is above is typically as deep as I go with it.
It adds an extra step, but it helps the team members inspect and adapt their own workload and capacity. This will also better enable them to meet their commitment in a Sprint; IMHO, the benefits of this far exceed the few extra minutes it will take for a team to make sure they are not overcommitting.