[QUESTION] Why Do Scrum Teams Call Agile Iterations “Sprints”?

The Scrum Guide tells us what a “sprint” is and gives best practices around duration and timing, but it says nothing about why scrum teams call iterations “sprints” in the first place.

phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr

This question actually came from a podcast that I listen to called This Agile Life.

John Sextro, Craig Buchek, Amos King, Jason Tice, and Lee McCauley publish this weekly podcast about life as agile coaches and developers.

On This Agile Life episode #64, the topic was Giles Bowkett’s blog post – How Scrum Should Just Basically Die in a Fire. I recently blogged about this same post, but did not comment on Mr. Bowkett’s disagreement with Scrum calling agile iterations “sprints”:

Scrum’s an agile development methodology, and one of its major goals is sustainable development. However, it works by time-boxing efforts into iterations of a week or two in length, and refers to these iterations as “sprints.” Time-boxed iterations are very useful, but there’s a fundamental cognitive dissonance between “sprints” and “sustainable development,” because there is no such thing as a sustainable sprint.

The This Agile Life crew zeroed in on this criticism and mused about asking Jeff Sutherland why he decided to call scrum iterations “sprints”. Fortunately, Mr. Sutherland has a new book out called Scrum: The Art of Doing Twice the Work in Half the Time AND he answered this question:

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

With the origin story in mind, the “sprint” label makes sense for scrum teams:

  1. The goal is intensity:  Scrum teams are laser focused on a sprint goal and work diligently on their sprint backlog items to turn their stories in to working software.
  2. Scrum teams take time to catch their breath: At the end of each sprint is a sprint review meeting. During the sprint review meeting, scrum teams stop to examine the sprint activities, the latest increment of software the team delivered, and the product backlog. The scrum team also conducts a sprint retrospective to examine how the team got to where they are and how they can do things better during the next sprint.
  3. Sprints are short for a reason: Mr. Bowkett is correct when he says that there is no such thing as a sustainable sprint. But short (2-4 week) sprints with time taken to inspect and adapt the work IS sustainable. Not stopping at the end of the time box jeopardizes sustainable pace as does going past the 1 month maximum sprint length.

Inspecting scrum is a great way to become a better agile practitioner. Podcasts like This Agile Life and blogs like Mr. Bowkett’s are great places to help you think about scrum and deepen your understanding about the practices that you use every day. It’s a tip that I’ve given in the past, but I cannot stress it enough as a great way to improve.

In this case, we learned that the label “sprint” is meant to give teams a sense of urgency, but with the intention of taking rest after the intense work it takes to turn sprint backlog items in to increments of software.

Question: What do you think about the term “sprint”? Does it express the right intention, or is it time to go back to “iterations”? You can leave a comment by clicking here.

Agile Coach Camp 2014 Was A Huge Success

During the closing circle of Agile Coach Camp 2014 our facilitator – Deb Hartmann Preuss – asked us: Which word described our experiences during the conference? The word that immediately came to mind was “humbling”.

CS | Share | Flickr.com

CS | Share | Flickr.com

Agile Coach Camp is an open space event. It’s an “unconference” where agile coaches network and develop relationships while inventing ideas, concepts and practices. The attendees come up with high-level topics and create their own conference agenda – better known as the marketplace.

They then gather around the topics that interest them and collaborate, plan, discuss, and dig deeper as a group to develop new “things”. You can fine more information about the open space concept here.

One of the interesting parts about this format is that the presenter is actually a facilitator. They are responsible for proposing a problem or an idea, but after that the session turns in to a dynamic group discussion.

At this year’s Agile Coach Camp, some of the biggest names in the industry showed up. People like Diana Larsen, Esther Derby, Don Gray, George Dinwiddie, and Tim Ottinger facilitated and presented alongside the other 90 participants.

While it was humbling, it was also amazing. Getting to exchange ideas with some of the best coaches in the industry was tremendous fun. That kind of interaction is simply not possible at the larger conferences. It is a level of sharing that I’ve never seen in a community.

In fact, many of the topics we discussed would not have made it in to the agenda of a traditional conference. Those events are filled with talks on metrics, agile tools, and scaling scrum.

At Agile Coach Camp, the focus is squarely on individuals and interactions and not process and tools.

To give you an idea of this, here are some of the sessions that I attended:

  1. Agile Game Mechanics (@paul_boos): A discussion on how traditional game mechanics – random event decks, dice rolling, character creation, quest mechanics, and action points – can be used to develop agile games and simulations.
  2. Conjoint Coaching (@gdinwiddie): Coaching teams as a whole and how to model behavior. Also a great discussion on observing teams and feedback loops to get to the core of what drives the way people interact on an agile team.
  3. Thinking for a Living (@tottinge): The challenges of breaking away from the factory mindset in an age where your job is to think, not assemble. We looked at how the brain works, how naps make people more productive, and even the best time to have a parole hearing (ego depletion example).
  4. BA’s Role on an Agile Team (@agilesquirrel): Where does a BA fit on an agile team? Should they be a scrum master or a product owner? Is “business analyst” a valid agile role? These questions and how to avoid a squirrel attack were covered in detail.
  5. Agile Coaching is Dead (@howardsublett): An incredibly honest discussion about whether or not agile coaching is a bubble ready to burst. We also dove in to the role that certification bodies play in the impending demise of the agile coach, along with what agile coaches can do to change direction and bring value to their customers.

The outcomes of these talks led to what many of us called “ideas too big to tweet”. The conversations were rich and we all walked away with new ideas and more importantly new friends.

This is now my favorite “unconference” that I will keep on my schedule for years to come. Next year Agile Coach Camp is in DC. I hope to see you there.

To read more about Agile Coach Camp 2014 and  the sessions you can visit the event log site here.

Question: Have you attended a conference that changed the way you look your work? Your life? Please share in the comments below. You can leave a comment by clicking here.

[QUESTION] Why Do Scrum Teams Estimate in Story Points Instead of Hours?

Management wants to know how long it will take to get something done. The problem is that people are terrible at estimating features in hours. Why? Because it is hard work, inaccurate, and not a lot of fun. Scrum teams have a better way – story point estimation.

Steve Dalton | Poker Planning | Flickr

Steve Dalton | Poker Planning | Flickr

Hours or duration is complex to estimate on software projects. Teams and individuals are expected to figure out how many hours a particular user story will take to implement – before doing any actual work. It’s not surprising that 60% of software projects fail at this task.

Hours have a different meaning to different people. Developers have varied skillsets, abilities, competencies, domain knowledge, and experiences. Given a diverse development team, a consensus on how many hours a user story will take to finish will be extremely difficult to reach.

For example, let’s take two developers – Senior and Junior. They have been asked to estimate USER STORY X. Senior, who has many years of experience, thinks that USER STORY X will take 5 hours to complete. Junior, who just graduated from college and is working at his first job, and thinks that it will take 10 hours to complete the story. There is no way to reconcile these estimates and reach consensus.

Even if the hours could be reconciled, the meaning behind the hour estimates are unclear. Is that 5 hour estimate expressed in ideal time or elapsed time? In other words, is that 5 hours of work assuming no interruptions, distractions, and other commitments? OR is that 5 hour estimate really 20 hours in duration because the work was spread over 3 days due to meetings, disruptions, or other life events?

Instead, scrum teams use story points – a unit of measure for the size of a user story. The actual values and units are not as important as the value of the stories relative to one another. A story that is a 10 should be twice the size of a story that is a 5. The estimate is also all inclusive. Everything that is need to get the user story completed is considered in the process.

In our case, Senior and Junior can decide that USER STORY X represents 1 story point. They could then look at other user stories on the product backlog and decide the story point value of the remaining user stories based on their relative size to USER STORY X.

This abstraction removes the complexity of estimating in hours and simplifies the estimate to a relative sizing exercise. Mike Cohn put it best in his excellent book Agile Estimation and Planning:  “A story-point estimate is an amalgamation [consolidation] of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherit in it, and so on.”

Hours based estimating is popular, but it is also more complex. It is also frequently wrong. There are many variables that are out of your control that you end up having to factor in (more guessing) or ignore (bad guessing).

Estimating is waste. Customers do not pay for estimates. You can’t claim ROI from an estimate. Scrum teams do not deliver estimates at the end of every sprint, they deliver working software. Estimates have no intrinsic value. So why invest a lot of time on them?

Since scrum teams know that they are going to be “wrong” when estimating, they use story point estimation to quickly and inexpensively size their user stories. As they inspect and adapt their work during and after each sprint, they can revisit their estimates and adjust as needed.

[QUESTION] When Does A Scrum Team Fix Defects From the Previous Sprint?

During our last sprint, a defect was reported against a user story from the previous sprint. I *think* we should create a new user story and plan on fixing the defect during the next sprint. Is this the right approach?

Paolo Valdormon | Bug | Flickr.com

Paolo Valdormon | Bug | Flickr.com

Let’s assume that the story was released to production after the previous sprint and that the product owner accepted the work. This means that the scrum team is in the middle of their next sprint and have an established sprint goal and sprint backlog.

With these types of questions, I like to start with the scrum guide:  “During a sprint, no changes are made that would endanger the sprint goal.”

According to the rules of scrum, the scrum team should treat the defect as a new PBI (product backlog item) and have it prioritized by the product owner. It can be added to the next sprint if it is ranked higher than the other stories on the backlog.

At the end of the current sprint, the scrum team should discuss the defect during the sprint retrospective and look for ways to improve their definition of done to prevent defects like the one reported from happening again.

That’s the theory. From a practical point of view, if the defect is minor AND can be rolled in to a story that is currently being worked on then the scrum development team can go ahead and fix it.

With that said, there is a common pattern that scrum development team must avoid. In these types of situations, many developers make the decision to fix the defect on their own.

The problem with this approach is that they could unintentionally impact a higher priority user story on the sprint backlog. This would put the  sprint goal is in jeopardy which is exactly what we are trying to avoid.

When fixing the defect could jeopardize the sprint goal the product owner must be brought in to the conversation.

The scrum guide also supports this approach: “During the sprint, scope may be clarified and re-negotiated between the product owner and scrum development team as more is learned.”

A reported defect is an opportunity for the scrum team to learn more about their software. It is also an opportunity to work with the product owner to determine the best way to handle the defect.

All software has defects. Some the scrum team finds, other remain hidden. Some defects get immediate attention, and others can wait.

This decision belongs to the product owner.

If the scrum development team decides to work on the defect without the knowledge of the product owner, they lose transparency. Without transparency it is impossible to properly inspect and adapt the scrum events and scrum artifacts.

This loss of insight in to the development process erodes trust between the scrum development team and the product owner. Under these conditions it is unlikely that scrum teams will achieve the results that are expected from agility.

If you have a question that you would like answered, please click here to send it in.

Question: How does your scrum team handle defects? What issues have you had with defects being prioritized next to user stories? You can leave a comment by clicking here.

5 Ways to Improve Your Scrum Game

With most games there are methods to getting better. Baseball players take batting practice, chess players solve tactical puzzles, and golfers practice the same swing over and over to improve accuracy and distance. But what about the game of scrum? What can scrum masters focus on to sharpen their skills?

5 Steps to Learning Scrum

(“Learning” by Anne Davis 773 from Flickr.com)

During a particularly difficult daily scrum meeting I noticed that the team was asking a lot of questions about scrum basics. When does the next sprint start? Why is this meeting only 15 minutes? Why do we have to table technical details until later? The entire team had just gone through scrum training and should have known these things.

At the end of the daily scrum I asked the team one final question:  Who here has actually read the scrum guide? Not every hand went up. I strongly suggested to the team that they read the scrum guide as soon as possible, and this is also my first suggestion for you:

  1. Read the Scrum Guide…Often:  I read the scrum guide 2-3 times per week. Why? Because each time I read it something new stands out to me. The time spent here is an opportunity for me to inspect my own understanding of scrum and to gain new insights.
  2. Focus on Relationships:  Not all problems can be solved with unit tests and pair programming. XP practices aside, poor relationship between the product owner and the end users can lead to requirements not being understood and features being rejected. Practice using the “Five Why’s” in cases where you suspect relationships are an issue. It is an effective tool that moves the conversation from the technical to the interpersonal very quickly.
  3. Inspect the Artifacts:  When reading the scrum guide, apply the pillars of agile (transparency, inspection, and adaptation) to the artifacts of scrum. The definition of done is an interesting place to start. It is a list of criteria that must be met before a feature can be called “done” (transparency). It is used by the developers and product owner to evaluate features during a sprint (inspection). During the sprint retrospective, the definition of done can be improved to meet the needs of the upcoming sprint (adaptation). Applying the pillars to the scrum artifacts is a great way to understand the “why” of scrum.
  4. Favor Empowering the Team:  One of the hardest tasks for a new scrum master is removing impediments. The urge is to jump in and solve the problems as they come up. But this does not create an empowered team. To truly empower a team, the scrum master must get comfortable with a key question. How can I coach the team to remove this impediment? Apply this question regularly and your teams ability to handle issues will grow.
  5. Promote Self-Organization: Scrum explicitly gives the power back to the developers. Respect this! Your developers know who is needed on the team to accomplish the sprint goal. Trust them to get the right work to the right people. Enable them to determine how the work will be done. Rules and mandates that come from outside of the team often end up as impediments during the daily scrum meeting.

It’s the soft skills that help us get better at scrum. In a profession where technical skills go a long way, this can be a scary. The good news is that you get better at scrum by being aware. The practices above promote awareness and lead to questions scrum masters should be asking themselves and the team members on a regular basis.

These discussions bring out a deeper understanding of scrum, which is bound to take your scrum skills to the next level.

Question: Do you think scrum is like other games that can be practiced? If so, which “drills” do you use to get better? If not, why? You can leave a comment by clicking here.