Scrum Fundamental: User Stories

In my line of work as an agile coach I get to help people who are just starting to use Scrum. Some common problems crop up with many of these teams. If often comes down to some Scrum fundamentals. Fundamental doesn’t mean easy. Professional athletes work at the fundamentals and so must we.

If I had a short list of common problem areas, the neglected fundamentals might be: good stories, “keep it working”, getting to done, collaboration, and planning. That’s a bit much for one blog post, so, maybe over the next few days I can address these in a series of posts. Here’s the first.

User Stories

Analysis of a business problem yields features that may either be “stories” or that may be broken down into stories. The first pass will have stories that have some very important parts as well as some less important parts. Identify and implement the most important stories first and address risk first. Defer as much as possible to the end of the project.

That sounds obvious, but it’s so easy for a developer to “just add this in while we’re working in this area.” It’s seductive to the Product Owner to want to “round out” some feature set. So many useless features and dead code gets bought and paid for that way.

Maximize the amount of work not done. Be ruthless in deferring what is less essential until later; you might not ever have to do it. Don’t build frameworks in advance or build support in for features you plan to work on later because You Aren’t Going to Need It – the well known YAGNI principle.

Split Stories

The approach here is to split your stories. The “User Management” story becomes “Add Users”, “Delete Users”, and “Modify Users”. You might never implement Delete, and Modify isn’t needed in the first release. You may further split Add User into basic and wiz-bang versions. This can likely be split further to deal with different types of users, assorted permissions, error cases, cascading, and more complex attributes of the user. After splitting, implement the most valuable stories first, of course.

Each story should have some value to your business/client/customer, particularly to an end-user. Each story should deliver some function from top to bottom. It should be a complete vertical slice through your application. Don’t divide stories along architectural lines. Avoid technical/horizontal slices (the DB framework, the complete object model, all the UI components). For the “user management” story, don’t have a story for the UI and a story for the backend.

Spike Stories

Use spike stories when you need to figure out how to implement or estimate something. A spike is a short time-boxed experiment or research, with a specific objective to address unknowns and risks. The conclusion of a spike may beget more stories and spikes.

Rules of Thumb

Some rules of thumb for story size:

• One story should not take the whole team more than half the iteration.
• The team should be able to finish any story in one to two days for a one-week iteration.
• The team should be able to finish any story in one to four days for a two-week iteration.
• Aim to have 3 to 8 stories for a one-week iteration.
• Aim to have 3 to 8 stories for a two-week iteration.
• If most of your stories can be done by a person in half a day, they are too small.
• If your team is doing more than 8 stories per iteration, your stories are too small.
• If your team is doing more than 9 stories in a three-week iteration, your iterations are too big.

Remember, these are just my rules of thumb. There are valid exceptions.

Summary

Poor stories will make Scrum painful. I’m not the first to write about good user stories, not the most eloquent, and won’t be the last. If what I’ve written describes your problem, read more about it or find a good coach. I’m available.

Question for the day

Disagree with my recommendation? Have a better way to word this? Hate my rules of thumb? Have a better blog post on user stories? Post your thoughts or post a link.

Scrum Master? Or coach?

I've seen many more open positions for Scrum Masters than I have agile coaches. I've been asked to be a Scrum Master more than I've been asked to be a coach. Is it just marketing? Scrum has market share; it's widely known and understood. Does the market distinguish between a Scrum Master and a coach?

I often find that companies looking for a Scrum Master want someone to run their standups, planning and retrospectives. They want an agile project manager to manage the projects, to report status, to track budget.

They seem to not want the change agent and process improvement aspects of the Scrum Master role. Or, they want a little change agent and process improvement to happen as long as it's directed towards the team and not management. And anything directed toward the team mustn't involve facilities or pair programming. Or HR. Or empowerment.

But isn't that what a Scrum Master is supposed to be, a coach?

I dislike this dichotomy.

There was a recent discussion on the Agile Alliance discussion group on LinkedIn about the career growth path of a Scrum Master. The question was, is there a growth path? I liked Irene Michlin's response:

Have they all brought their teams to "performing" stage? Process is perfect, as in "nothing left to improve" a constant motive in retrospectives?

They are either all very brilliant and need to go and become trainers and coaches, or they don't get what it means to be a Scrum Master.

If there is something left to improve, then your job as a Scrum Master is not done -- you haven't mastered Scrum Mastering. Or, at least you aren't done coaching. But there is that distinction again.

I dislike this distinction between Scrum Master and coach. Unfortunately, I find it useful. It's a tell, as in poker. It helps evaluate an opportunity. It's how the conversation goes. "No, I won't be your Scrum Master, but I'll gladly train your team to handle this role. I'll be your coach. Are you ready for a change agent?" Sigh. I find it useful, therefore I tend to perpetuate the distinction.

What should we do? Not use the term coach and elevate the term Scrum Master? Should we live with it because it is what it is? Once the dichotomy is there it's not possible to kill it. Is there a useful distinction between the two?

CAN: Shifting the Voice of the Business to the Team

I've been thinking about Mike Cottmeyer's "12 Keys to Success with Agile", specifically his bullet #3, single voice of the business, where he says "This cannot be shifted to the team..."

It can.

Earlier this week Scott Chacon of GitHub presented his approach to projects, called Developer Driven Development, in a keynote address at CodeMash 2011. I won't try to explain DDD here, since the details aren't germane to this post.

However, key to DDD is that you must have careful hiring practices, careful to the point that you only hire people that already demonstrate a commitment to the project and possess great knowledge of the domain. (My words, not his, but I think he'd agree.) Hire those that are already involved in the project or in related ones. Clearly, to be already involved in the project before you are hired likely implies you are either involved in an open source project or are an actively involved customer or user of the product, be it open source or commercial.

Can that be applied to Corporate America? Not completely sure, but we can certainly apply some lessons. If your team hasn't already caught the vision, you need to help them catch the vision. This is important on any project, agile or not. But its importance is indirectly proportional to the extent to which you have an effective voice for the business involved with the team. That is, the less that the team understands the business need already, the more that vision casting is needed. The more that the team knows the business need own their own, the less involvement the team needs from "the business".

I've been on at least one team of note in Corporate America that the single voice of the business was successfully shifted to the team. In this case the team sold the business on a need. The team was given the leeway to run with the idea. Each person brought to the project what they thought the project needed. Each person on the team had a voice in prioritization. Anything that was to get done had to have the support of the team. (So, this wasn't a free-for-all to the extent that an open source project would be. Everyone did not go off and build whichever feature they wanted. The team agreed to the iteration's backlog.)

This worked because the team wanted it to. We wanted to keep doing what we were doing. We liked the product, the project, the team. To keep it going we had to demonstrate value to the organization that was paying the bills. So, we listened to those using the product and took their needs and suggestions into consideration.

It worked much like the open source model: I build what I want, what is interesting to me. But motivation is multifaceted. I'd like help from others, so I have to consider their interests. I'd like my product to be useful, to be used. I'd enjoy a little fame or appreciation from others. I'd like enough money out of the project to take money off the table. So if I'm relying on the product to pay the bills or support my multifaceted motivation, then I'm going to listen to my users and supporters.

It's going too far to say that you cannot shift "single voice of the business" to the team. A trusting cross functional team with empowered team members sharing accountability who have the vision can BE the single voice of the business.

Wearing the Right Hat

A Scrum Product Owner at a client of mine once told me he didn't trust development to build what he wanted built. Sadly, I find this quite common with the more technical POs. The lack of trust was largely due to his negative experience with some other dev team at a different company. His concern was that future value would be blocked by using a simplistic approach now. This PO therefore stepped way over the PO/DEV responsibility line into specifying some of the "how" for a set of stories.

Lack of trust is a significant issue. I could have told the PO that he needs to be able to trust the team. I could have suggested he create opportunity to build that trust, or change the team. Either way, that would take some time and we can work on that. But that's not the focus of this post.

And I could have explained emergent design and the danger of over-architecting things now. I could have told him YAGNI, but have also said that it is okay to share the big-picture vision with the dev team. That it's okay for the dev team to think about where they are headed long term as long as they "pay as you go" and not design and build too much up front. But that's not the focus of this post either.

The focus of this post is that I told him it was okay for him to not trust the developers for now and that it was okay for him to step over the line.

Now, before you take away my Agile Badge, let me explain myself.

Product Owner	Architect

I told the PO that if he is technically capable and can pull it off, then he can AT THE APPROPRIATE TIME review development's planned approach and make suggestions. I told him he can have a PO hat and an architect hat, but that he can only wear one at a time and he needs to wear the correct one at the correct time. He must wear the PO-only hat and only the PO hat during the planning game. Once the business requirement is sized, split, resized, scheduled, and planned, he can visibly remove his PO hat and put on his architect hat during the design and tasking part of the sprint.

In this case, I told him that I believe he is wrong and most likely doesn't need what he was requesting and that what he was requesting will greatly complicate the design and require much much more code than necessary. There was a better approach. Nevertheless, I didn't tell him not to put forth his ideas. For me, it's just a matter of timing.

What would you have done?

Estimating Defects - Using Principled Negotiation

I’ve caught myself changing my stance on pointing defects this last month as I consider different contexts and reflect on what the real situation is in my current teams.

Previously, my general rule was that if we don’t fix it a bug in the iteration in which it’s found (which would be the best thing to do), then it needs to be estimated before being scheduled into a future iteration. If we don’t fix it now, it will be more expensive to fix later. We should recognize that cost. This will help us know when we'll be done with the release. If we have a significant amount of work to do represented in defects, I want that quantified and represented in the release burn down chart. I acknowledge that defects are hard to estimate. Their accuracy will be worse than that for stories, but I don’t see this as a significant problem. The value we get from knowing when we will be done is worth the difficulty.

Mike Cohn recommends estimating defects if you have a big backlog of them and are fixing new ones as they come in. But that 'if' is important. Don't ignore the context. A similar context was underlying my rule of pointing defects. I assumed that if you were having the discussion about whether to estimate defects, then you must have defects that weren't being fixed in the iteration in which they were found. In that case, you likely have more than a few defects in the backlog and you aren't likely to have a policy defining a systematic approach for fixing issues. You'll schedule the defects into iterations just like you schedule stories. A systematic approach, by comparison, could be knocking out all the defects in the next iteration, or knocking out a fixed number each week. In those cases, I wouldn't estimate.

It was Dan Neumann's thoughtful post that made me realize I was making too big of an assumption about the context at hand. He also helped me realize that interests matter. Principled negotiation is when you consider each party's interests, not their positions. ("Getting to Yes" is an excellent book by the way.) For this topic, the positions are whether to estimate defects, and if you do, whether to include those points in velocity and in the release burn down chart.

But the interests are more varied and may include:

INTEREST: A desire to measure "forward progress". As Cohn put it, "making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found."
CONTEXT:  Most any.
POSITION: Don't point defects. Or, do point, but don't include those points in the velocity or in the release burn down chart.

INTEREST: A desire to keep anyone from thinking that scope is increasing. A desire to keep the release burn down chart from going flat, or up, due to defects. (It’s embarrassing and requires lots of effort to answer executives' questions: “Why is scope increasing?" "Why do we have so many defects?”)
CONTEXT:  Applies to any context, but in particular when defects are not being attacked in a smooth, systematic manner.
POSITION: Don't point. Or, do point, but don't include those points in the velocity or in the release burn down chart.

INTEREST: A desire to make velocity appear unstable so that quality problems become visible.
CONTEXT:  Defects in the backlog are not being attacked smoothly (a set number per iteration).
POSITION: Don't point. Let the uneven defect fixing impact velocity.

INTEREST: A desire to make velocity appear more stable. (Similar to the case above with a rising release burn down chart, an unstable velocity makes executives ask questions that can be hard to answer.)
CONTEXT:  Since the work effort applied is generally stable each iteration but the balance between defects and stories might not be, pointing defects makes velocity more stable.
POSITION: Do point and include the points in the velocity.

INTEREST: A desire to know when we are going to be done with all the stories AND defects.
CONTEXT / POSITION 1: Defects are not being attacked in a smooth, systematic manner. This interest can be served by pointing defects and including the points in the release burn down chart and in the velocity.
CONTEXT / POSITION 2: This can also be served by not pointing AS LONG AS you are addressing issues on a steady basis (so that your velocity is stable and therefore useful in computing the release end date).
CONTEXT / POSITION 3: Another approach is to address all of the issues immediately in order to get them out of the backlog. Point them or not; doesn't matter.

See how a single interest can be served with different contexts and different positions?

INTEREST: A desire to avoid overstating velocity.
CONTEXT:  Estimating and including recently introduced defects in velocity. The excellent concern is that "the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced" and pointed. (Dan Neumann)
POSITION: Don't point, or don't include in velocity.

INTEREST: A desire for velocity to "… represent the team’s true capacity to accomplish work." (Cohn) Or, a desire to make velocity look better than it really is. (A desire to pacify upper management that wants to see a rising velocity number. A losing game, by the way.)
CONTEXT:  Most any.
POSITION: Do point.

INTEREST: A desire to get credit for work done, which is less justifiable if it’s our own rework and more justifiable if the bug was caused by another team.
CONTEXT:  Most any, but needing to get credit signifies an illness in the organization.
POSITION: Do point.

INTEREST: A desire to avoid the need to argue about a bug report actually being a story (so that we can estimate it for whatever reason makes us want to estimate it).
CONTEXT:  Applies to most any context, but this probably signals some animosity or lack of trust between the Product Owner or QA and the rest of the Technical Staff. At best, this may just be a desire to hold to the team's aggressive commitment.
POSITION: Do point.  If you point them, then it's easier to quantify how much more you did beyond the commitment.

INTEREST: A desire for the Product Owner to weigh the cost before requesting a fix.
CONTEXT:  Most any.
POSITION: Do point. Whether to include the points in the velocity is another matter.

The pie can be expanded for each of these positions once the interests are known. One party may become aware of an illness in the organization and see a way to cure it. One of you may be able and willing to educate the executives or boldly attack the quality problem. Maybe an unstable velocity and an increasing release burn down chart should be welcomed as an opportunity to talk to those executives about agile, metrics and what-not. Agile believes that visibility is good.

Bottom line – Use principled negotiation to understand stakeholder interests and the full context. Then devise a defect handling policy that specifies when defects will be handled and whether they will be pointed. The way you use iteration and release metrics needs to be in tune with all of that.

Parting shot – A tremendous amount of effort is expended on this topic for a situation we'd rather not have in the first place.

'Tis the Season for Pair Programming

There are few things that disturb a pair programing environment more than futzing with your nose. Chewing on pens or a lanyard or one's own fingers is not cool, but runs a distant second to nose fiddling.

Luckily, 'tis the season in which many offices have so called "holiday parties". What's this have to do with pairing ettiquite? Gift exchanges. That's right. Office parties often involve Secret Santas or White Elephant / Dirty Santa gift exchanges. What a great opportunity to make a few improvements to your agile environment! Few pair programming teams have the guts to directly confront issues of social graces. So, why not conspire with others to make sure that "special someone" has lots of opportunity to draw the perfect gift, and then get stuck with it?

So here are my ideas, your shopping list, for things to gift your pair to help keep his hands away from his face.
These are truly gifts for the whole team. No, really. These are gifts the whole team should go out and purchase.

• Tissues. Tissues are more than a subtle hit. Hopefully they'll be used. Disinfectant wipes are almost in this category, though they do more to counteract the behavior than to correct it.
• Decongestant. I rub my nose a lot more when it's stuffy. That may be why your pair does it.
• Allergy medicine. Itchy eyes, itchy nose; He's gonna rub 'em.
• Fingernail clippers. What better gift than a manicure kit for one who chews his fingers? Well, here's one...
• A gift certificate to The Boardroom Salon for Men. If you don't live in Texas, there's bound to be something similar in your own town. Just... not as big... or as manly.
• Hand sanitizer. Not only is it good for rubbing on your hands, it's also something that's uncomfortable when rubbed in the nose. It's kind of like using pepper to keep a toddler from sucking her thumb.
• Gum. Altoids. Mints. Jolly Ranchers. A variety is a must. These have the added bonus of attacking bad breath. This is also the one suggestion that can keep your lanyard and pen eating pair on a more healthy diet. (Surely, sugar is a more healthy diet than a piece of plastic.) These items may also give the incessant talker something else to do with their mouth.
• A nose hair trimmer.

Some Essential Items

That's right. A nose hair trimmer. This is an essential item, right up there with dental floss and a tooth brush. Every man should have one. I think men mess with their noses more than women and I'm convinced the problem is nose hair. Notice mine in the photo. (Referring to my trimmer.) The buttons are worn off. Pssst. That's a clue for anyone working on that last minute gift idea for me.

White Elephant exchanges are supposed to be unusual and humorous.These gifts would certainly be unusual. I would find them humorous, and taken in the spirit of the event, I'm sure you will too. Most importantly, the team would find this beneficial. Guaranteed to increase your velocity 10 percent. What else can promise that? If most of your team will stick with this list, some good is bound to come of it.

My Road to Agile

For those of you without the patience to read yesterday's long post, here is the abridged version. My route to agile wasn't overnight.

Fist exposure to an automated regression test suite in '89 (with the IBM 3174 Communications Controller).
Many years of coding and laboriously testing stuff by hand.
Wanted to try my hand at management in '96.
Project managed wrongly what could have been a nice agile project.
Felt ignorant.
Started studying.
Went back to programming.
Fell into an XP project in '99.
Fell in love with XP.
Studied it.
Tried to spread it.
Practiced it on a number of projects.
Wrote about it.
Spoke about it.
Disappointed people didn't flock to it.
Wanted to try my hand at managing in an agile fashion in '05.
Did much better.
Wanted to practice it on more projects, so became a coach for hire.

The moral of the story:
Consider all that led up to you buying in. Then guide and encourage those you work with, but give people space to find their own road to agile. Have patience with those you coach.

photo credit: Tomasz Wiech

How I Got Into Agile

This is long, but there is a moral to the story.

I had been programming for several years when I became tired of supporting the PPP and Frame Relay code in IBM's first router. No, that's not it. What really drove me away was the threat of having to pick up support for LU6.2. Maybe it wasn't LU6.2. Maybe it was something else, but it was definitely SNA. That's not the direction I wanted to go in. I wanted to work on IP. Any part of IP. I'd have been happy supporting basic IP, UDP, TCP. Developing any of the routing protocols would have been great. That's where the future was going to be. SNA? Yuck.

Prognostication in the early '90s -- score one for me.

I pleaded with the manager of the IP group to take me on. He had no openings. Or he no likey me. Or I had no IP knowledge. Whatever.

My manager at the time was Tom, a great manager and a real character. Tom was often railing about how many worthless meetings we had and how many people we had in them. Tom wrote a program in those days to compute the cost of meetings. All you had to know was the salary bands for the various levels and what level each of the attendees were -- stuff most people knew. Today you can get a program that does this for your iPhone. I digress. Tom was disappointed by my desire to leave his group, but was supportive in helping me find a place where I could grow and be happy. We'll come back to Tom in a bit.

A good friend, Sam, was working in the same division on some Smalltalk apps. Cool stuff, I thought, but I didn't realize how cool. Smalltalk will never make it, I thought. "What you are doing is kind of hard to buy into", I thought. C++ is where you want to be. I later said the same thing about Java.

Prognostication in the mid '90s -- Although Smalltalk didn't make it in the market, it would have been the thing to learn. Score one for me against Smalltalk's market-share; But -1 for being against Smalltalk as an important language; -1 against Java.

Sam's manager, Joe, offered me a position and made hints toward his retiring soon. I was thinking that if I couldn't work on IP I just might as well go into management. So I joined up. Sure enough, Joe very soon retired and handed the reigns over to me.

Now back to Tom. Not one month into my new role as manager, something was found to be lacking in our software. I don't recall whether it was a bug or an enhancement request. Whatever it was, Tom needed it for his product. My former manager, Tom, was now my customer. So, wanting to be a strong manager with a backbone, one who could make the tough decisions and stand by them, protect his team and his schedule, I said no. I either said simply 'no', or I gave him a delivery date way out in the future, which might as well have been 'no'. Although Tom was the man who helped me get this job, had given me a promotion along the way, and was now my customer, and although his request was quite small, I said no. When I became a manager I threw out the window all I knew about being collaborative. I stopped practicing what I believed in as a developer. I did what I thought managers were supposed to do. Tom wasn't my only customer. I had bigger customers with big projects and big demands. Tom was furious.

What I didn't know then was that this team of Smalltalkers was quite agile. Of course, we didn't have that term back then. Gosh. This was in the midst of the ISO 9000 certification heyday. I had to document our process. I never new managers had to do that kind of stuff! "What have I gotten myself into?" I thought. I really didn't know how to describe our process. I kind of knew what we did, but document it? I knew I'd need help and thought the team would be as annoyed as I with this task. I dreaded asking the question and I didn't fully understand the answer: "Iterative and Incremental" with a few other words wrapped around it. So, I wrote down Iterative and Incremental on the process document, wrapped a few other miscellaneous made up words around it, then whipped out MS Project and got my project plan in shape. And it was a doozey! Spread out, the project plan covered a very large conference room table. I was so proud. (But it was really quite disgusting.) I could demonstrate when we'd be done (well after everyone wanted it), how I carefully put the plan together (with painstaking detail), and how many more expensive Smalltalk contractors we'd need (don't ask). I knew nothing of negotiating scope. I project managed wrongly what could have been a nice agile project.

I knew I was missing something. I felt ignorant so I started studying. I went back to programming while trying to figure out what I was missing. Steve McConnell's Rapid Development and Steve Maguire's Debugging the Development Process and Fred Brook's The Mythical Man-Month stand out as books that began to point me in the right direction.

Then in '99 I discovered jUnit and very soon after got invited onto an XP team, thanks to Greg Houston. Greg would say I resisted XP. Perhaps I did. But I soon fell in love with it after I got used to pair-programming. That took some number of months. Then I began studying XP, writing about it and tried to spread it. I was there at the start of XP Atlanta, which was led at the time by Obie Fernandez and which we later renamed Agile Atlanta. I attended XP Universe in 2001. I practiced XP on a number of projects then started speaking about it within the company, at a local user group and at a nearby college. I also submitted an experience report and a research paper to XP 2003 in Genova. I knew I'd be using agile for a very long time.

I thought I could convert people, that people would readily see the light and that in just a few short years everyone would be doing XP. They would be won over by my passion if nothing else. People would flock to our XP user group. jUnit would lead people to XP and the XP books would convert everybody. And I knew this would happen throughout the industry.

Prognostication in the early '00s -- score one for industry wide fear, uncertainty and doubt with a big helping of resistance to change.

My Prognostication Score: 2 out of 5.

After some years of being an agile developer and advocate in an organization lukewarm to the concept, I decided that I wanted to get onto a team where everyone really wanted to do XP and management supported it. And I wanted to try my hand at managing again, this time in an agile fashion. I found such a team to manage and I did much better this time (though considering how bad the first time was, this might not be saying much). This project eventually brought me to my desire to practice lean/agile on more projects, so I became a coach for hire.

So that's how I came to agile and here's the moral of the story: I think it's important to remember the route you took and how long it took. For most of you I suspect it wasn't really overnight. It might seem that way on the surface. "I got the book, read it, tried it, loved it, all overnight." Not likely. There was a road that got you prepared for the switch. Those we work with, those we try to coach, are on their own road. Have patience with them.

photo credit: Tomasz Wiech

Getting Started with Kanban - Answers for Some Mechanics

Let's assume you've read David Anderson's excellent Kanban book. You've started using Kanban on a project. Everyone notices how much more transparency there is in the process now. Some welcome that visibility. Others are not so happy about aspects of that visibility.

If you are reading this blog, you are probably not after Mechanical Agile. You are smarter than that. You want to add real value to your organization. You know that Kanban can help your team focus on flow and continuous improvement if you can figure out, in practical terms, how to use these metrics.

Let's say you've started well, with an understanding of what is important to your business and you have an improvement goal. Maybe you want to start measuring cycle time, want to have a Cumulative Flow Diagram and want to create a frequency distribution diagram or process control chart. You are getting started but the book leaves many details about how to do that as an exercise for the reader. Rightly so. You certainly wouldn't want a specific tool to be prescribed just as Kanban doesn't prescribe which improvement model to use, of which there are many: Deming, Lean, Theory of Constraints, etc.

Thinking back on some questions I had when I started using Kanban I realize many of them had nothing to do with improvement models. They were more basic. In hopes that this may help you, I provide some of the answers I've come across or come up with. I give credit for the good answers to conversations I've had with Dennis Stevens and others. The stupid answers are all mine.

After counting days blocked, do you exclude those blocked days from each item's duration?
No. What you are after with cycle time is how long on average it takes to pull something through the system. Blockage happens. It's part of the cycle. You want to know how long it will take to get an average story through the system with average blockage. You use the days blocked as another, separate metric available for analysis and improvement.

When something has been on hold for a long while and gets dumped, do you include that item in your average cycle time calculations?
Sometimes things get blocked so long that that you give up. Or should give up. Toss that effort in the trash. Forget about it. Write it off. Maybe it will come back again someday, but when it does, you might as well start over. Just dump it. Don't directly include that item in your average cycle time. I say don't "directly" include it because it has had an impact on the metrics. It took up time and effort and caused other items to be delivered later than they could have been. So that item had an impact on your cycle time even though you exclude that item from the metrics. If you were to consider the item's end date the date it got blocked and include that item in the average cycle time, this would make your cycle time look shorter than it really is. Conversely, you could skew your cycle time towards having too much buffer if you held onto the item too long and consider its end date the date you dumped it. So, no, don't include the item in your average cycle time.

Do you include weekends in your lead time calculation?
Eh, do whatever you want. If your average lead time is greater than a week and if your business thinks in terms of calendar time, include them. If your average lead time is around a week or less and if your business thinks in terms of business days, then exclude weekends. Excel has a networkingdays function you can use.

=NETWORKDAYS(B34,C34,'KanBan.xlsx'!holidays) 

For quick items that start and end on the same day, should I count it as a day or as a half a day?
If your average cycle time is much greater than a day and this happens rarely, count it as a day. It's not worth the effort to do differently. If it's rare that any item takes 2 days to finish, then consider measuring at a granularity finer than a day -- measure in hours. If your average cycle time is a couple days and this happens often enough, count it as a half-day -- measure in half-day increments.

How do I graph a frequency distribution using excel?
Use a bar chart. I put the cycle time durations I care about in a column: .5, 1, 2, 3, 4, 5, 6, 7, 8, etc. These are the "bins" that feed the FREQUENCY formula. Name the binsRange and name the durationsRange. Next to those bins, is an array formula: select the range, type in the formula =FREQUENCY(durationsRange,binsRange), and press ctrl-shift-enter. Then I graph the bins and frequency as a bar chart as shown in the image at the top of this blog post.

How do I graph a Statistical Process Control Chart using excel?
I'm assuming you already have columns for completed date and duration. There must be a better way, but the quick and dirty approach is to add a column for the mean and upper and lower control limits and upper/lower spec limits. These columns will have the same value (the mean, or the mean plus/minus three standard deviations, or the spec limit) in all rows. Select those 5 or 7 columns: date, duration, mean, upper/lower control and upper/lower spec limit. Insert a X Y (scatter) chart. Select the mean series, right click, and Change Series Chart Type to a Line chart. Do the same for the other control lines. Voilà!


I hope this has been useful. If so, let me know.

What questions of this sort have you resolved or do you still have?

Looking Ahead

I like to pass along my thought process and habits to those I work with. (Which is good because, well, it's what I get paid to do.) For example, I'm always looking ahead to the next planning or the next estimating meeting. I teach this behavior to my clients whenever I'm coaching a new Scrum Master or Product Owner.

I start off by involving them in what I'm doing, showing what needs to be done and by explaining my thinking. The teaching is very experiential, yet incomplete in a way. If I explained everything in my head, everything I was looking out for, I'd be doing too much telling and not enough involving.

Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
- Confucius, 450 B.C.

Yet there comes a point where I'm about to push them out of the nest and let them fly solo when I become more explicit about teaching my thinking. This leads me to throw down a list of things to remember, to refer to later, always tailored to the local context. Experience tells you what to look for and this is somewhat different in each situation so please don't expect this to be an effective checklist for your organization. But in general I keep the following questions in mind.

I look at the stories that haven't been estimated as well as the next iteration or two.
Can the team estimate the story?
Can the team plan the story?
Are the descriptions good?
Are the acceptance criteria sufficient?
Is the story too big?
Does the team need to do a spike first?

How does the next iteration look?
Too many points? Not enough?
Are there un-estimated stories in there?
Are the stories prioritized?
Have we given the team some advance notice as to what we have in mind for the next Sprint?

If we have specialization or multiple teams for one backlog, should we think about which team should take each story?
Does the next iteration look balanced between the teams/specializations?

How does our release burn-down look?
How does the release backlog look?
Will we have stories ready and estimated in advance of the start of the next release?
How much lead time do we need to need?

If I'm using an online backlog management tool, am I overlooking some stories not in my standard filter because they haven't yet been slotted into an iteration or assigned to a team?

When using an online tool for backlog management, I set up views or queries to help us answer those questions:

• No Estimate
• No Team
• No Sprint
• This Sprint
• Next Sprint
• Release Plan

That's provided naturally by some tools, can be set up with a little work in other tools, and is downright impossible in others.

Looking more than one iteration ahead, are there holidays coming up that will fall on a regularly scheduled estimating or planning day (or a pre-planning/pre-estimating day)?

The Scrum Master can help keep an eye on things and point out what is lacking, but the bulk of the decision making of course belongs to the product owner.

I hope you find this useful.

photo credit: Tomasz Wiech