I've added a Scrum Glossary to the site. It's something I've been planning to add from the beginning, but didn't have time to get started until now.
Some of you may have noticed that there is some inappropriate capitalization in this blog. This is intentional and should be considered a "domain thing". Within the domain of this blog, certain terms will (or at least should) be capitalized that are defined in the Scrum Glossary. I will do my best to link the first use of any of these terms in a post to the Glossary and, over the coming week or so, will add links to the existing posts.
Please use the comment tool below to let me know if this is useful or if anything in the Glossary needs refinement.
Thursday, April 24, 2014
Tuesday, April 22, 2014
The Scrum Manager
One of the lesser-discussed roles in the Scrum universe is that of the Scrum Manager. This can be a Software Development Manager, (who supervises Software Engineers and Quality Assurance personnel), a Software Engineering Manager or a Quality Assurance Manager.
The reason this role is not discussed often is because Managers are Chickens -- people who are involved in the process of delivering software, but who are not making the personal commitment to a Sprint's completion. Scrum literature doesn't tend to focus on the Chickens.
While many Managers believe that they should be considered members of the Scrum Team and treated as Pigs, their job role disqualifies them: their presence on the Team would invalidate the Principle of Self-Organization.
That's one of the reasons I started this blog -- to talk about the role of Managers in Scrum.
So where do Managers fit into the Scrum framework? Explicitly, we don't, because Scrum is intentionally "incomplete" or under-defined, both to emphasize the parts of the framework that are defined and to remind us that Scrum is still an Agile process and requires customization on how the remainder of the structure gets built.
So the formal definition of Scrum appears to leave Managers out of the picture. That doesn't mean we have no role in Scrum, it only means that Scrum doesn't define it.
I won't call it a series, but for the next several weeks, the bulk of the posts I'll be making will be related to how I see my role as Software Development Manager within the Scrum framework. Think of this as an introductory post.
I'll be fleshing this out with specific practices over the next few weeks, but for now, here is the core of what I believe makes a good Scrum Manager: a leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.
The reason this role is not discussed often is because Managers are Chickens -- people who are involved in the process of delivering software, but who are not making the personal commitment to a Sprint's completion. Scrum literature doesn't tend to focus on the Chickens.
While many Managers believe that they should be considered members of the Scrum Team and treated as Pigs, their job role disqualifies them: their presence on the Team would invalidate the Principle of Self-Organization.
That's one of the reasons I started this blog -- to talk about the role of Managers in Scrum.
So where do Managers fit into the Scrum framework? Explicitly, we don't, because Scrum is intentionally "incomplete" or under-defined, both to emphasize the parts of the framework that are defined and to remind us that Scrum is still an Agile process and requires customization on how the remainder of the structure gets built.
So the formal definition of Scrum appears to leave Managers out of the picture. That doesn't mean we have no role in Scrum, it only means that Scrum doesn't define it.
I won't call it a series, but for the next several weeks, the bulk of the posts I'll be making will be related to how I see my role as Software Development Manager within the Scrum framework. Think of this as an introductory post.
I'll be fleshing this out with specific practices over the next few weeks, but for now, here is the core of what I believe makes a good Scrum Manager: a leader who creates and maintains an environment that emphasizes trust, personal development and transparency while protecting the team from influences that would disrupt the Sprint -- including himself.
Wednesday, April 16, 2014
Weekly Story Sizing
The standard Scrum framework prescribes a Release Planning ceremony with a recommended time box of four hours to two days. And this ceremony, when performed properly, works as one of the major columns in the Scrum architecture.
The problem for many teams is that it's hard to keep the attention of a team for two days on a single task -- and it's often difficult to schedule a quarterly two-day meeting. This varies from team-to-team and company to company. Some can facilitate the traditional Release Planning time box easily, where others find it much more difficult. And as a result, unfortunately, many teams drop this very important structural element.
One of the groups I worked with was experiencing that pain, and was heading in the same direction of just dropping the ceremony. I proposed we keep the ceremony but look for ways to make it work.
Those of you who are familiar with it, know that the great majority of the time spent in Release Planning is spent in Story Sizing. For a typical team, a two-day Release Planning meeting is comprised of an hour and a half of presentations by the Product Owner with team and stakeholder input -- followed by over fourteen hours of Story Sizing.
My plan was to separate Story Sizing into a separate ceremony, leaving the rest of the Release Planning agenda intact. This change allowed us to still "do Scrum" with only the timing and frequency of the Story Sizing task altered from the original framework.
Coincidentally, about two months after we successfully separated Story Sizing from Release Planning, I found a couple of blog posts from Scrum Masters who had come up with almost identical answers to the problem. And about six months later, a Scrum Extension was published that documented the variation as well.
Here's what we do:
The Product Owner, who is also responsible for the Release Planning Ceremony, schedules a weekly Story Sizing meeting that lasts exactly one hour. For our group, one hour a week was sufficient to keep our Backlog maintained and the relatively short time period helped focus the team on quick, from-the-gut sizing.
During the meeting, the Product Owner presents the highest-priority story in the Backlog that has no size to the team. There is a brief discussion of the story and any refinements that might need to be made to it to make it sizable. The team then plays a round of Planning Poker to determine the size of the item. This process is repeated with the next-highest un-sized items in the Backlog and continues until we run out of stories or run out of time.
This has worked very well for teams I've worked with, and it has some nice advantages in that new stories that need to be brought into an on-going release don't require a special meeting in order to get sized -- they get sized as a result of on-going process and are normally ready before the team schedules them into a sprint.
I would note that teams starting Scrum should not try this first! Always run the framework in its entirety and get some experience with it before seeking alternatives.
Also, this meeting is not the same as Backlog Grooming. That is an additional process that is often employed by Scrum teams, but it is not the same as Weekly Story Sizing.
The problem for many teams is that it's hard to keep the attention of a team for two days on a single task -- and it's often difficult to schedule a quarterly two-day meeting. This varies from team-to-team and company to company. Some can facilitate the traditional Release Planning time box easily, where others find it much more difficult. And as a result, unfortunately, many teams drop this very important structural element.
One of the groups I worked with was experiencing that pain, and was heading in the same direction of just dropping the ceremony. I proposed we keep the ceremony but look for ways to make it work.
Those of you who are familiar with it, know that the great majority of the time spent in Release Planning is spent in Story Sizing. For a typical team, a two-day Release Planning meeting is comprised of an hour and a half of presentations by the Product Owner with team and stakeholder input -- followed by over fourteen hours of Story Sizing.
My plan was to separate Story Sizing into a separate ceremony, leaving the rest of the Release Planning agenda intact. This change allowed us to still "do Scrum" with only the timing and frequency of the Story Sizing task altered from the original framework.
Coincidentally, about two months after we successfully separated Story Sizing from Release Planning, I found a couple of blog posts from Scrum Masters who had come up with almost identical answers to the problem. And about six months later, a Scrum Extension was published that documented the variation as well.
Here's what we do:
The Product Owner, who is also responsible for the Release Planning Ceremony, schedules a weekly Story Sizing meeting that lasts exactly one hour. For our group, one hour a week was sufficient to keep our Backlog maintained and the relatively short time period helped focus the team on quick, from-the-gut sizing.
During the meeting, the Product Owner presents the highest-priority story in the Backlog that has no size to the team. There is a brief discussion of the story and any refinements that might need to be made to it to make it sizable. The team then plays a round of Planning Poker to determine the size of the item. This process is repeated with the next-highest un-sized items in the Backlog and continues until we run out of stories or run out of time.
This has worked very well for teams I've worked with, and it has some nice advantages in that new stories that need to be brought into an on-going release don't require a special meeting in order to get sized -- they get sized as a result of on-going process and are normally ready before the team schedules them into a sprint.
I would note that teams starting Scrum should not try this first! Always run the framework in its entirety and get some experience with it before seeking alternatives.
Also, this meeting is not the same as Backlog Grooming. That is an additional process that is often employed by Scrum teams, but it is not the same as Weekly Story Sizing.
Tuesday, April 15, 2014
The ScrumMaster Manager
One of the most undesirable, but often implemented roles found in organizations is the ScrumMaster Manager. It's usually the result of companies believing that they can't afford to have an independent ScrumMaster role and interpreting the role as a supervisory position. It's also sometimes just the result of having only a limited number of staff available combined with a strong desire to implement Scrum.
In my case, it was the latter.
Wearing these two hats is very difficult, especially since it's hard for your team members to distinguish between the Manager and the ScrumMaster -- and for the Manager to know that he needs to shut up and be a ScrumMaster. Over the past four years where I've had the combined role -- and believe me, I've tried hard to rid myself of it -- I've had to develop a set of skills that let the ScrumMaster clearly shine through when the Manager needed to take a back seat.
It's not a perfect marriage, and, quite honestly, it's one that should always be looking for a divorce.
I've been able to make it work, to a degree -- I'll never say it really worked -- by creating an environment of trust not only between my team members, but between each individual team member and me. The most valuable tool for doing that has been my weekly one-on-one meetings with each team member.
That level of trust is what has made it possible for me to still act as ScrumMaster during team retrospectives. But there again, it's been a hard role for me. My natural bent as a Manager is to contribute and steer the meeting that I am officiating. But as the ScrumMaster, my role should be more in line with a Master of Ceremonies -- keeping the team on the agenda, but not steering the direction of the conversation.
Even though I've done it, and with a significant margin of success, I think the blended role of ScrumMaster and Manager is a Bad Thing. It's another one of those Agile Smells to be avoided.
Why do I mention this now? I just read a good article on Len Lagestee's blog called "A Managers' Guide to Attending Agile Team Events". In it he tells Managers "Don't attend [Sprint Retrospectives], ever." I really wanted to kick at the goads and say "but... but.. but...I've made it work!" My experience is the exception but I also know that my blended role has interfered with the retrospectives, though not as drastically as it could have. Even so, in my remaining time at my current blended role, I plan to step away from the retrospectives. My team is certainly mature enough in Scrum to do it on their own, and has in the past when I was the SM for multiple teams running simultaneous Retrospectives. Len's advice is a good wake-up call -- and advice that I would have given to anyone else... just not to myself. Sigh. Sometimes you really can't see the forest for the trees.
Once again, it's time for me to Be Brave and Do What's Right.
Do you need to be brave as well?
In my case, it was the latter.
Wearing these two hats is very difficult, especially since it's hard for your team members to distinguish between the Manager and the ScrumMaster -- and for the Manager to know that he needs to shut up and be a ScrumMaster. Over the past four years where I've had the combined role -- and believe me, I've tried hard to rid myself of it -- I've had to develop a set of skills that let the ScrumMaster clearly shine through when the Manager needed to take a back seat.
It's not a perfect marriage, and, quite honestly, it's one that should always be looking for a divorce.
I've been able to make it work, to a degree -- I'll never say it really worked -- by creating an environment of trust not only between my team members, but between each individual team member and me. The most valuable tool for doing that has been my weekly one-on-one meetings with each team member.
That level of trust is what has made it possible for me to still act as ScrumMaster during team retrospectives. But there again, it's been a hard role for me. My natural bent as a Manager is to contribute and steer the meeting that I am officiating. But as the ScrumMaster, my role should be more in line with a Master of Ceremonies -- keeping the team on the agenda, but not steering the direction of the conversation.
Even though I've done it, and with a significant margin of success, I think the blended role of ScrumMaster and Manager is a Bad Thing. It's another one of those Agile Smells to be avoided.
Why do I mention this now? I just read a good article on Len Lagestee's blog called "A Managers' Guide to Attending Agile Team Events". In it he tells Managers "Don't attend [Sprint Retrospectives], ever." I really wanted to kick at the goads and say "but... but.. but...I've made it work!" My experience is the exception but I also know that my blended role has interfered with the retrospectives, though not as drastically as it could have. Even so, in my remaining time at my current blended role, I plan to step away from the retrospectives. My team is certainly mature enough in Scrum to do it on their own, and has in the past when I was the SM for multiple teams running simultaneous Retrospectives. Len's advice is a good wake-up call -- and advice that I would have given to anyone else... just not to myself. Sigh. Sometimes you really can't see the forest for the trees.
Once again, it's time for me to Be Brave and Do What's Right.
Do you need to be brave as well?
Monday, April 14, 2014
Scrum Time Boxes Visualized
For a couple of years now, I've used a diagram created in an Excel spreadsheet to explain to new team members how the various Scrum time boxes interact. Here's a screenshot (click to enlarge it):
The columns in the SPRINT portion of the diagram represent work days. It should be noted that a Scrum work day doesn't necessarily start in the morning -- it starts with the Scrum.
Feel free to use this image in your team training.
If you don't recognize the "Story Sizing" ceremony, it's something we do a bit differently from traditional Scrum, but that has been adopted by many organizations. We came into it organically before I saw mention of it in other Scrum literature. Perhaps that will be the topic of a future Scrum Now!
Feel free to use this image in your team training.
If you don't recognize the "Story Sizing" ceremony, it's something we do a bit differently from traditional Scrum, but that has been adopted by many organizations. We came into it organically before I saw mention of it in other Scrum literature. Perhaps that will be the topic of a future Scrum Now!
Thursday, April 10, 2014
Don't be afraid to make course corrections
About two years ago, I made a change to our Daily Scrum. Instead of having each person answer the Three Questions*, I had someone volunteer each day to M.C. the Stand-up and call off the stories that were currently in-progress. Each person who had worked on the story since the last Scrum then answered the Three Questions in relation to the current story.
This was a Scrum Extension** that was proposed sometime back called the "Feature-focused Daily Scrum" and it seemed like a good idea for mature Scrum teams. And the truth of it was that for well over a year, this "advanced" format worked very well.
Recently, though, I'd noticed that I was getting less and less input from some of my team members under this format. Our Scrum was starting to feel stale. On top of that, the team dynamics had changed significantly and I had some new people who were getting their first real exposure to Scrum.
It was time for a change.
In our Sprint Retrospective I announced that we would be going back to the classic Scrum format where each person answers the Three Questions for all of the work they did since the last Scrum. This was greeted with some minor support from my developers and, oddly, disdain by my QA personnel.
But this was a Scrum Master decision, not a team decision -- that's the nature of some procedural things in Scrum -- and I asked the team to try the classic format for a Sprint.
And it worked.
Everyone is contributing again and I'm getting more interaction than I got before. Oddly, the perception of the team is that they are interacting less under the original format, even though the meetings are running about 2-3 minutes longer. We discussed the change after the trial period at the next retrospective and, for the most part there was enthusiasm for the change.
Scrum requires that you and your teams be brave. You don't bully, you don't command, but you often have to be brave -- even if it means admitting you were wrong or that the environment has changed and left you behind. That's Agile.
-------------------
* Three Questions: "What have you done since the last Scrum?" "What will you do today?" "What roadblocks are in your way?"
** Scrum Extensions are a now-maligned idea where Scrum.Org was hosting moderated white-papers on extending Scrum. This practice has been discontinued in recognition that Scrum should be intentionally simple and incomplete -- a framework that teams fill in with the processes that work for them.
This was a Scrum Extension** that was proposed sometime back called the "Feature-focused Daily Scrum" and it seemed like a good idea for mature Scrum teams. And the truth of it was that for well over a year, this "advanced" format worked very well.
Recently, though, I'd noticed that I was getting less and less input from some of my team members under this format. Our Scrum was starting to feel stale. On top of that, the team dynamics had changed significantly and I had some new people who were getting their first real exposure to Scrum.
It was time for a change.
In our Sprint Retrospective I announced that we would be going back to the classic Scrum format where each person answers the Three Questions for all of the work they did since the last Scrum. This was greeted with some minor support from my developers and, oddly, disdain by my QA personnel.
But this was a Scrum Master decision, not a team decision -- that's the nature of some procedural things in Scrum -- and I asked the team to try the classic format for a Sprint.
And it worked.
Everyone is contributing again and I'm getting more interaction than I got before. Oddly, the perception of the team is that they are interacting less under the original format, even though the meetings are running about 2-3 minutes longer. We discussed the change after the trial period at the next retrospective and, for the most part there was enthusiasm for the change.
Scrum requires that you and your teams be brave. You don't bully, you don't command, but you often have to be brave -- even if it means admitting you were wrong or that the environment has changed and left you behind. That's Agile.
-------------------
* Three Questions: "What have you done since the last Scrum?" "What will you do today?" "What roadblocks are in your way?"
** Scrum Extensions are a now-maligned idea where Scrum.Org was hosting moderated white-papers on extending Scrum. This practice has been discontinued in recognition that Scrum should be intentionally simple and incomplete -- a framework that teams fill in with the processes that work for them.
Monday, April 7, 2014
Bad Coffee, Good Will
During the course of our most recent release, my team decided to use the theme "Coffee Flavors You'd Never Want To Try" for naming their sprints. (We try to make sprint naming fun. Can you tell?)
The team came up with some absolutely disgusting coffee flavors: Salmon Roast, Moldy Sunrise and Pickled Onions, to name a few. Toward the end of the release, I thought it would be fun to make these coffee flavors a reality.
I bought some 1 lb. kraft paper coffee bags, the kind with the window on the front and the metal twist tie at the top. I also bought ten pounds of roasted coffee beans in bulk. I put a pound of coffee in each bag and then, with the help of Bing Image Search, created a label for each of the coffee names my team came up with.
The bags were put on display in the conference room where we had our Release Retrospective and it was a great surprise for most of them. (I'd let one of my guys in on the idea weeks earlier, but he had no idea I'd gone through with it.) Everyone got to take home a pound of coffee that they'd named.
This was great fun, the team loved it, and I spent just under $100 to get it done. The photos below were taken in the conference room just before the team showed up for their retrospective.
What fun things have YOU done for your team's Release Retrospective and Celebration? Use the comments below.
The team came up with some absolutely disgusting coffee flavors: Salmon Roast, Moldy Sunrise and Pickled Onions, to name a few. Toward the end of the release, I thought it would be fun to make these coffee flavors a reality.
I bought some 1 lb. kraft paper coffee bags, the kind with the window on the front and the metal twist tie at the top. I also bought ten pounds of roasted coffee beans in bulk. I put a pound of coffee in each bag and then, with the help of Bing Image Search, created a label for each of the coffee names my team came up with.
The bags were put on display in the conference room where we had our Release Retrospective and it was a great surprise for most of them. (I'd let one of my guys in on the idea weeks earlier, but he had no idea I'd gone through with it.) Everyone got to take home a pound of coffee that they'd named.
This was great fun, the team loved it, and I spent just under $100 to get it done. The photos below were taken in the conference room just before the team showed up for their retrospective.
What fun things have YOU done for your team's Release Retrospective and Celebration? Use the comments below.
Friday, April 4, 2014
Seven Ways to Fail at Scrum -- Part Four
Here is the final installment of my mini-series on bad Agile smells I've experienced.
Smell #6: Not Performing All of the Scrum Ceremonies
Scrum has a number of time-boxed events, collectively referred to as Ceremonies, that must be performed in order to support the framework. Omit any of the ceremonies and you aren't doing Scrum. I know there are those of you reading this that think I'm a purist and that some of the things we do in Scrum are only marginally useful and therefore a waste of time. But the truth is, if you are doing them correctly, none of them are a waste of time, and together they make a strong and well-supported framework on which you can do good development.
Here are the Scrum Ceremonies:
- Scrum (aka: Daily Stand-up)
- Sprint Planning
- Sprint Review (formerly called the Sprint Demonstration)
- Sprint Retrospective
- Release Planning
- Release Retrospective
- Periodic/Weekly Story Sizing (this only applies if you don't do sizing as a part of Release Planning)
Every team I've worked with, even before I was familiar with Scrum, I had a standing rule: "I will never commit my team to unnecessary meetings. If a meeting has limited or no value, it gets eliminated. If you think a meeting is unnecessary, tell me and we'll discuss its elimination."
The six/seven Scrum ceremonies are all necessary. But here's how it tends to break down when people try to do Scrum buffet style:
- All teams do the stand-up. Unfortunately, a lot of groups think that by doing just this one thing, they are "doing Scrum".
- Most teams do Sprint Planning, since it's an obvious necessity.
- Slightly fewer do the Sprint Review, with those dropping out thinking that it is an unnecessary formality. "The customer will see the product when it's shipped."
- More teams drop the retrospective, since "it's just going to be a bitch-fest, anyway."
- There's then a big drop in groups performing Release Planning. The excuses start mounting up: It's harder to coordinate; it takes time away from "productive" work; "We really don't know what's ready to work until we get to sprint planning, anyway."
- And there's a huge drop in groups doing Release Retrospectives. Again, it can be difficult to coordinate. "Besides, we covered all that in the Sprint Retrospective, right?"
My teams have always done the morning Scrum, Sprint Planning, Sprint Review, Sprint Retrospective and Weekly Story Sizing. If I tried to drop any of those ceremonies, there would be Hell to pay because my teams know those ceremonies have value. We worked as a team to ensure that they were (and are) valuable experiences.
We dropped the Release Planning and Retrospective at one point. Not intentionally, but because those two ceremonies are hard to coordinate at times. Especially since Releases are only marginally related to Sprints and Releases can overlap, with work beginning on a new release often weeks before the current release is delivered to Software Configuration Management. I realized after almost a year of not doing them that I wasn't doing Scrum -- I was missing two important tent poles. So I bit the bullet and worked with my Product Owners to re-introduce them.
The result was amazing -- and it shouldn't have been.
Almost to the person, my team members came to me afterward and told me how good these meetings were; how they improved their perspective on the on-going direction of the product; and why weren't we doing these before? My team members aren't gluttons for punishment. They tell me when they've been to a bad or worthless meeting. And here they were, again, almost to the person, telling me how much they appreciated these "new" meetings.
Scrum is not a buffet -- don't do it a la carte.
Smell #7: Not Respecting the Sprint Time Box
The following conversation actually occurred, though it may be a bit paraphrased. Some of you may think I'm making this up; I assure you I am not. Others may recognize it because, they too are not respecting the time box.
The participants in this dialog are a Product Owner from another set of teams in my company, denoted as "PO", and me.
PO: It looks like one of my teams is going to have two stories incomplete this Sprint. It's so frustrating.
Me: I understand, but they'll get finished at the start of the next sprint, so they'll still make it into your release.
PO: Oh no. They have to stay unfinished for at least another sprint. Our next sprint is already full.
Me: (doing a coffee spit-take) Excuse me? How can it be full already?
PO: It's full. There's no room for those stories to be finished.
Me: Oh, so these stories are lower-priority than the stuff that's already in the sprint?
PO: No, they are higher priority. This keeps happening and it's really annoying.
Me: (doing spit-take number two after foolishly sipping my coffee again) WHAT? I'm missing something here. Why are higher-priority, unfinished stories not at the top of your next sprint.
PO: Because the sprint has already been planned.
Me: Already planned? Today is Friday. Your next two-week Sprint starts on this upcoming Wednesday, right?
PO: Yes...
Me: So... (realization dawns) ...when did you do Sprint Planning for next week's Sprint?
PO: Two days ago, on Wednesday, before the team realized these stories wouldn't get finished.
Me: (safely not spitting more coffee on my monitor because I saw it coming) So, let me get this straight, your TEAM is doing Sprint Planning a week before the sprint starts while the current sprint is on-going?
PO: Of course. There's no time to do it any closer to the sprint -- we'd be in a whole day of meetings.
Me: (More coffee on the monitor, darn-it) You realize that it takes the same amount of time whether its on the same day as the demo and retrospective or not, right? I mean you don't actually lose a day. You just allocate it differently.
PO: You guys do something different?
Me: (Feeling faint.) Yes. We do Sprint Planning for the new Sprint after the Sprint Review and Retrospective for the prior Sprint. That way we automatically transfer unfinished stories to the top of the new Sprint if we have to.
The good news is that, as a result of that conversation, the Product Owner's teams reorganized so that the Sprint Time-box was no longer intermingled with the prior sprint.
The Time-boxes were created so that Scrum processes work. Respect them so that you can work, too.
Wednesday, April 2, 2014
Seven Ways to Fail at Scrum -- Part Three
Here is Part Three in my series on bad Agile smells I've observed.
In this particular company, one of the managers is responsible for "calculating" the velocity for all of the teams working on the product. I've quoted the word "calculating" because, while that's what she says she's doing, I'm suspicious that she's actually creating velocities as a way of motivating her teams. I should also note that this product group is guilty of Smell #5 below -- correlating story points directly to man hours. The Managers have unilaterally decided that one Developer working with one QA Engineer during the course of a sprint defines eight story points -- essentially assigning a velocity of four points per person per sprint. The velocities the teams are challenged with (and I use that term intentionally in this case) tends to be slightly higher than that raw calculation, which fosters my earlier suspicion that the secret calculation is aimed at pushing or motivating the team.
So why is this a bad smell? Because it hits hard against two core principles of Scrum!
The first violated principle is that of Transparency. Velocity should be a simple matter of looking at a team's average story points over the most recent sprints. It's not hard to calculate and it should be something transparently presented to the team as a statement of the team's current performance and predictor of future performance. In this product group, velocity is being used as a whip against the team instead of as a tool for Product Owners to predict what features are likely to fit into the next release.
The second principle violated is -- you guessed it -- self-organization of the team. (It's amazing how many bad smells come back to a violation of self-organization, isn't it?) The team uses velocity as one of its indicator tools when preparing a sprint during the Sprint Planning ceremony. Combined with predicted task hours, velocity is a way of sanity checking whether or not the team can complete the work it is about to commit to. If a team tries to commit to 40 points of work when its established velocity is 20 points, the Scrum Master needs to be throwing flags on the field -- even if the tasked hours look feasible.
Smell #4: Secret Calculations for Velocity
I'll admit, when I heard about this one, my jaw literally dropped wide open with a "Whaaaaaaa...?" I don't think I even added the terminal "t" to the word. This is one of those bad smells that you can't even conceive where it came from or what motivated it. I want to think it's unique to the company where I saw it, but as Solomon once mused, "there is nothing new under the sun", so I'm sure it's happened before and may still be happening elsewhere.In this particular company, one of the managers is responsible for "calculating" the velocity for all of the teams working on the product. I've quoted the word "calculating" because, while that's what she says she's doing, I'm suspicious that she's actually creating velocities as a way of motivating her teams. I should also note that this product group is guilty of Smell #5 below -- correlating story points directly to man hours. The Managers have unilaterally decided that one Developer working with one QA Engineer during the course of a sprint defines eight story points -- essentially assigning a velocity of four points per person per sprint. The velocities the teams are challenged with (and I use that term intentionally in this case) tends to be slightly higher than that raw calculation, which fosters my earlier suspicion that the secret calculation is aimed at pushing or motivating the team.
So why is this a bad smell? Because it hits hard against two core principles of Scrum!
The first violated principle is that of Transparency. Velocity should be a simple matter of looking at a team's average story points over the most recent sprints. It's not hard to calculate and it should be something transparently presented to the team as a statement of the team's current performance and predictor of future performance. In this product group, velocity is being used as a whip against the team instead of as a tool for Product Owners to predict what features are likely to fit into the next release.
The second principle violated is -- you guessed it -- self-organization of the team. (It's amazing how many bad smells come back to a violation of self-organization, isn't it?) The team uses velocity as one of its indicator tools when preparing a sprint during the Sprint Planning ceremony. Combined with predicted task hours, velocity is a way of sanity checking whether or not the team can complete the work it is about to commit to. If a team tries to commit to 40 points of work when its established velocity is 20 points, the Scrum Master needs to be throwing flags on the field -- even if the tasked hours look feasible.
Smell #5: Correlating Story Points Directly to Ideal Man Hours
This smell is pervasive. It's hard to get past. We all want to quantify our work in terms of time. It's natural. We've been asked to do it all our lives.
"When will you be finished?"
"What time can I expect you?"
Relative sizing isn't hard, but it's hard to break ourselves from the habit and mindset of predictive hours. It's especially difficult for individuals with a scientific or pedantic bent; less so for those who are more kinesthetic. This is complicated by the fact that we see the Product Owner (correctly) using our Velocity to project features against a release date, so, as developers, we see another argument to correlate back to time.
But despite what you might read in Henrick Kniberg's otherwise excellent and seminal white paper "Scrum and XP from the Trenches: How We do Scrum", story points need to be about a from-the-gut feeling regarding a story's size and not an estimate of time.
The psychology and reasoning behind why we should size things from the hip and relate them to the bigness of a well-understood story is a topic way beyond the scope of this particular series, but it has been exhaustively discussed throughout the Scrum literature. For the purpose of this post, let's just take it as given that relating story points to any unit of time during the sizing phase of a story is a Bad Thing.
If there's curiosity about sizing expressed in the comments, I'll consider making a more in-depth post.
Subscribe to:
Comments (Atom)