Individual Capacity Calculator

(This is an update to my 10/28/12 post on How to Avoid Overcommitment During Sprint 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.

Here is the file
(Link updated July 2019)

This work is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

.

Personal Kanban - Week 1

This Dysfunction Goes to Eleven

When this experiment started one of my goals for the first time box/iteration was just to see if I could actually give up my Things task list and follow the practice with a board. I had tried a number of other productivity frameworks and found that only pieces of them stuck. (Someday someone will write on a book on how to finish David Allen’s “Getting Things Done” book and I’ll actually get all the way through it.) And while I know that limiting work in progress is a cornerstone of this type of approach, and I did set WIP limits, I decided to be a little loose with the limits since I was just guessing at what they should be.

Because my larger plan is to test out different approaches to Personal Kanban, I wanted to start as simply as I could manage. I created a task board and began to fill it with post-its. The first lesson I learned was that I had far too much in my to do list to fit on my Kanban board. I decided to limit it to the things that seemed to be the most important at the time.

The Architect of my Own Demise

The most basic way to set up my board would have been to create three columns: On Deck, Doing and Done. I know this. However, when I sat down to work on it, I began struggling with how I would be able to visually understand the different types of things I had to do. My plan was to use this not just for work, but for my whole life. So, I made a decision to start with multiple swim-lanes. This is a choice I can’t say I was entirely comfortable with. It seems to violate (my current understanding of) one of the basic premises under which this system is designed to work.  But… (I bargain with myself) baby steps. I decided that this would be an okay thing to try while I am working on coming up with a better solution.

I started off by dividing my Backlog up into 5 swim-lanes, each feeding into it’s own On Deck and Doing columns (instead of having just one of each). I was able to limit myself to one column for Done though. The reason for this is that there were/are so many things I felt compelled to work on that I was afraid if I put them all in one box, without some kind of designation, I’d lose sight of something critical. (Yes, I realize this is a broken way to look at it.) There was also a part of me that was curious about how I would work through the prioritized items once they hit the On Deck boxes. The swim-lanes I set up were:

• Work-ish: Obviously for things somewhat related to work
• Reading (later changed to Reading and Research): self explanatory
• SA/IT2: for work/volunteering I do for the Scrum Alliance and IT2
• Personal Daily: These are things I do every day that I track
• Personal: Personal projects and tasks I need to take care of
• 
  

So here is my basic organizational system:

Even with the swim lanes I was still concerned about understanding the tasks on the board. Not so much from a priority standpoint, because I can handle that pretty easily with the On Deck backlogs. The desire for clarity is more about having a visual way to quickly understand that a given task is related to (work, personal, reading, etc.) This should have been easily handled by the swim-lanes, but there were sub groups I felt I needed to identify even within the lanes. So, I began with a variety of different sized and colored post-its, each one loosely designated to belong to some kind of additional detail on a task.

One of my challenges was (and continues to be) defining “value”. I believe the multi-colored, multi-sized post-its are part of trying to define that. There are tasks that obviously provide direct value to customers, like send Client X a demo license. There are items which provide indirect value to my ability to do my job: Read the new book by Diana Larsen book, “Liftoff: Launching Agile Teams and Projects”. There is work I do volunteering for organizations which provides value for others: Review submissions for Scrum Gathering. But there are other things I do which appear to be valuable only from the perspective of their impact on my body, brain or mood. How to capture this value in relationship to other items in the list continues to be a struggle and is one of the reasons for the multiple swim-lanes in my board. (How for example do I quantify and prioritize based on value if what I am comparing is the value of sending a client a demo license, compared to the mental health boost I get from meditating each day, or maybe just sitting back to read a comic book for fun.

It would be easy to argue that the non-work items do not provide value to a client and do not need to go on the board. But that seems to me to be a pretty thin definition of value. My goal was to try to put everything on the board. The problem was, it didn’t all fit. . One of the most important things I learned that week was that if I don’t put it on the board, it isn’t going to happen. So, I needed a kind of backlog nursery, where I could dump ideas and then periodically replenish the backlog on the board from that nursery.

I decided to hold a little personal retrospective at the end of each week to evaluate how things are going. The first week was really difficult for me, not because following the process was hard – that was actually pretty easy. The hard part was that Nigel Tufnel stopped by to crank the volume on my “obsessive tendencies” up to 11. Here are the important (and painful) things I learned about myself during week 1.

• While some of the PK books will tell you to plan to do the unpleasant work first and then work your way towards the stuff you want to do, I found that if I don’t force myself to do the things I want to do, that I cram every possible minute full of the not-fun work and never get around to the enjoyable, recharge-oriented items on my list. (Remember, this is my vacation too.) I actually had to block out time to stop being productive and just sit around and read a book or play my guitar for fun.
• I was so focused on getting the items across my board as efficiently and quickly as possible that I actually spent a few nights tossing and turning in a restless series of dreams about the board, the tasks and how to move them. (The last time I had dreams like this was during my brief, but disturbing addiction to playing Doom and Quake. Unfortunately, this time I didn’t get to wake up and grab the BFG to kill off some monsters.)
• In my crowning moment of idiocy that week, I climbed off the treadmill halfway through a long workout because I realized I had not moved the card into the doing column. I was unable to continue the workout until I had the car in the right column. (Yes, I have issues.)
• Throughout the week I found I was still using Things. As eager as I was to embrace the new system, I was still afraid to let go of the method I had developed in order to keep things from slipping through the cracks.

At the end of the first week, I know I have a long way to go. I’m nowhere near ready to deal with WIP, the waste I am creating or finding a better way of doing this. But, it’s a start. And, by the end of the week I was able to start talking myself down off the ledge of obsessing about moving the cards....

But, they say admitting you have a problem is the first step to recovery.

Here is a snapshot of my board as I got ready to start on the 2nd week.

The Drunken PM meets Personal Kanban

For the past 18 years I have been developing my skills at helping people manage the work they have to do into a state of ninja-like perfection-ish. As I have progressed in my career I have had the good fortune to work on projects of varying size, duration and cost. Some have been successful, but more have not – and that is okay because those are the ones where I’ve learned the most. To demonstrate my proficiency in my chosen profession I have obtained multiple certifications to prove I know how to manage work in both a traditional approach and an Agile approach. I’ve even spent years teaching others how to get those same certifications. Along the way I also got an MBA to demonstrate… whatever it is an MBA is actually supposed to demonstrate beyond that I am willing to be in debt until I go to my grave.   And I’ve given up thousands of hours of personal time leading volunteer organizations that focus in managing work and teaching people how to get better at it.

After all that, I feel it is fair to say I am fairly well versed in how to manage projects and I’m pretty good at it.  My experiences have taught me many things… most of them the hard way. And with this, I have found only one single truth that spans all of it:

Being skilled at helping others manage their work is no guarantee you will demonstrate any level of skill at managing your own.

In fact, I think it is fair to say I pretty much suck at managing my own work. I’m not saying I am not good at getting things done. I get stuff done all day long, and usually, it is the most important stuff. But I’m not good at managing it.

When I started working in project management, this was not a problem. It was 1995. I did not have a cell phone. I had one email account and I could log into AOL from home or work via my 14.4 modem. There was literally only so much information I could access in a day. Compared to now, the information overhead I faced on a daily basis was pretty light. My weekly to do list usually looked something like this:

This is a sheet of notebook paper folded in half 3 times, so that each side contains 8 boxes just like the one above. When the section of the paper got too crowded, I’d copy the open items to a new section and start again. A single sheet of paper torn from a notebook could usually take care of my list of to-dos for 2-3 weeks. (This was how we did things back in the olden days before the Palm III.)

And now, as I am writing this, blog posting about having too much to do, Things has 170 items in it waiting for me to get to. Granted, they aren’t all due today but it is so many that even trying to manage what I am not going to do has become pretty much impossible. I’ve tried many different approaches and finally reached a point where I thought I had it sorted. At that point, my goal, with any single piece of information, was to get it out of my head and into something more responsible as fast as possible. For me, this means put it in Things if it is an action I have to take care of, in Evernote if it does not go in Things and on those occasions where I am not able to access electronics, I have my overpriced Field Notes notebook and one of those weird sticks that ink comes out of. With this I have gotten very good at making sure I capture everything worth capturing. But dealing with it after… that is where things get wonky.

This past December I found myself in the bizarre position of having to take a whole month off from work. It was that or lose the vacation time. While I’d expect this would sound like a truly wonderful opportunity to most people, it scared the crap out of me. The problem was, I had so many things I wanted to do during my vacation that I was pretty sure I’d end up just curling up in a ball on the couch and watching all 10 seasons of MI-5 again just to avoid having to pick which thing I was going to take on first.

As much as I love MI-5, I didn’t think I’d be able to cope with losing Tom, Zoey and Danny again, so I decided to do something about it. And, since one of the main things I do for a living is teaching Agile, I decided to practice what I preach and started getting set up to give Personal Kanban a try.

I’m writing this after 5 weeks of my own attempt at Personal Kanban. I've been holding a retrospective once a week and keeping a journal on how it is going.  My current plan is to keep working with it and experimenting with different practices to see what works for me and what doesn’t. I’ll be posting back to this blog about once every two weeks with updates on what I’ve learned and what I’m going to try next.

A friend of mine once told me that when he met with new clients about Agile Transformation, he tried to focus on making sure they understood that Agile was not going to make them faster, but it would make the broken ugly things so obvious that they’d have no choice but to deal with them. I’ve seen that happen over and over in my own work. I am happy (and totally annoyed) to report that the exact same thing happens when you apply the practices at a personal level. 

If you are interested in learning more about how to apply Kanban to managing your personal work, you might try Personal Kanban by Jim Benson and Tonianne DeMaria Barry.

How to Avoid Overcommitment During Sprint Planning

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:

• Standing Meetings  - recurring meetings held each week that will keep them from working on the project
• Holiday/PTO - expected
• Vacation/Sick time - expected or averaged
• Medical/Dental/Other Personal Appointments - expected or averaged
• Emergency Fixes* - average time lost per Sprint to emergencies which require them to temporarily abandon their work on the project
• Misc. Additional Time - Any additional time they feel they should block out to address other issues, work or personal, which will inhibit their ability to contribute to the project during the Sprint

* 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:

• 4 hours standing meetings
• 8 hours PTO
• 3 hours for dentist appointment
• 5 hours average time lost to Emergency Fixes
• 5 hours subtracted because I will just be returning from overseas and I expect the jet lag to have a negative impact on my productivity for a few days

Interruption Time (IT) = 25 hours

45 (MPPH)

- 25 (IT)

20 (RMPH) 

If I am split across 2 projects at 50% each...

20 (RMPH)

*50% allocation

10 hours

-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. 

Catching up... Podcastapalooza

I'm ludicrously behind in keeping the blog up to date... working on that... here is a list of all the podcasts I've done for Projects At Work since The last posting about Mitch Lacey. There is a lot of great Agile stuff here...

Howard Sublett from BigVisible
Part 1 of 1

Martin Rosenqvist on Agile Transformation
Part 1 of 2
Part 2 of 2

Tom Kealey on Getting Agile transformation to Stick
Part 1 of 2
Part 2 of 2

Kenny Rubin on his new book Essential Scrum
Part 1 of 2
Part 2 of 2

Dan Greening on Enterprise Scrum
Part 1 of 3
Part 2 of 3
Part 3 of 3

Interview with Mitch Lacey, author of The Scrum Field Guide

Mitch Lacey

My Projects at Work podcast interview with Mitch Lacey, author of The Scrum Field Guide.

Also, check out my review of the book here.

The Scrum Field Guide: Practical Advice For Your First Year
Written by Mitch Lacey, published by Addison-Wesley Professional as part of their Agile Software Development Series)

One of the things that is difficult about taking a Certified Scrum Master or Certified Product Owner classes is that to a large extent, the material looks at Scrum in a state that is (for many) based on an ideal they may never reach. Once students leave the class and go back to work, the number of obstacles they face in the struggle towards Agile transformation can be a daunting thing to overcome. If they are brave enough to take up the challenge, they soon bang up against the fact that when they try to apply Scrum in the wild, what they end up facing may not sync up so well with what was taught in class.

Enter Mitch Lacey’s new book: The Scrum Field Guide:Practical Advice For Your First Year. The Field Guide picks up where the classes leave off and addresses some of the real world issues that people face when they go back to their workplace and start trying to implement Scrum and Agile.  In a narrative that is unassuming and easy to read, Mitch Lacey shares stories, his own experiences, and advice from other expert sources on how to actually get Scrum up and running and producing results.  The book covers some of the most common questions that come up during implementation like:

When we don’t know what our velocity is, what do we tell our stakeholders we can commit to?

What if you have to play two roles at once?

How do you deal with team members that are only needed for brief, very specific types of work?

How is Scrum Master a full time job and how to you convince others of that?

The cases are presented through stories that set up the different situations. Lacey then draws on his own experiences leading and coaching Agile teams to explore the different options and offer his recommendations.

The book also includes a “First Aid” section for those who are trying to solve very specific issues with things like “Running a Productive Daily Standup Meeting” and dealing with some of the cultural challenges that are part of Agile Transformation.

While it is called the Scrum Field Guide, the book is not just about Scrum. Lacey introduces his own practice of Agile by saying that for him, one of the keys to getting Scrum to work has been pairing it with Extreme Programming. Throughout the book, Lacey introduces XP practices where he has seen them effectively utilized with Scrum.

While the book does include information on the actual Scrum Framework (in the Appendix) it is really designed to work best for folks who have a bit of experience in using Scrum and are seeing various issues, or “smells” as they are often called, creep up.

There are a lot of books out there that are aimed at clarifying what the Scrum Framework is. If you have clarity on what Scrum is supposed to be, and need a resource to help you make it work, The Scrum Field Guide will be a great addition to your tool belt. The title of the book indicates that this book is intended for people who are in their first year of doing Scrum. I’ve been working with Scrum for many years now and I’m also a Certified Scrum Trainer. I still found a lot of valuable information in this book and expect it is something I’ll be referencing in the future when I’m coaching.

Important Links:

Scrum Field Guide on Amazon

MitchLacey.com

@mglacey

Projects@Work White Paper - Distributed Agile Teams: Achieving the Benefits

ProjectsatWork has published a study called Distributed Agile Teams: Achieving the Benefits. The report was put together by Elizabeth Harrin  (@PM4Girls), who is the author of the website A Girls Guide to Project Management. The results of the research cover a lot of ground with respect to what makes distributed Agile projects work and what can contribute to their failure.  The report is very insightful and definitely worth the time it takes to read. While some of the findings may seem like common sense, knowledge workers in the IT space (myself definitely included) seem to possess a remarkable capacity for periodic loss of grip to that tether.

My favorite part comes at the very end during the summary of recommendations. Number One on the list is:

Don’t act like your project is co-located – pay the tax for distribution. 

This is one of the most simple things that so many of us forget when we are working at a distance. I believe this applies whether you are working down the hall from someone, or across the globe… there is a price that has to be paid when you are not sitting in the same room. With the transparency that Agile offers, this tax becomes far more obvious. There is no doubt that distributed teams provide a number of benefits, but those benefits come at a cost. The reason (IMHO) so many people struggle so much with distributed is that they keep thinking that the ride is free ... which it theoretically could be… unless you actually want it to work.

Woefully behind in the blog (again)

Today is the day I am trying to get caught up on the blogging.

Here is a link to the ProjectsAtWork : Agile Coaches Corner  interview I did recently with Xavier Quesada.

Part 2 of the Roman Pichler Interview (Podcast)

And my Projects At Work: Agile Coaches Corner interview with Ray Lewallen.
I've got lots of blogging to catch up on, there will be more posted very shortly.

New Stuff Posted on Projects at Work

Part 1 (of 2) of my interview with Roman Pilcher is live -> http://www.projectsatwork.com/content/PodCasts/270538.cfm

Blog Post: How Much Do We Actually, Really, Totally Need To Do? -> http://www.projectsatwork.com/blog/Dave-Prior/5063/