Category Archives: scrum

Estimating Tasks and Management’s Role in Scrum

Leave a reply

Team Estimation BoardHere’s an interesting question that just came in from a local scrum master. It’s about estimating tasks and management’s role in choosing the practices that a scrum team uses.

Question

Chris,

The team I am working with wants to do an experiment where they will stop estimating tasks in hours. Their sprint burn down will then be tasks vs. days instead of hours vs. days. The team believes that they will be successful with this and they are also thinking of creating an initial working agreement for this experiment e.g. any task that will be added will not be longer than a day of effort.

I am supporting this but somehow I have failed in explaining and convincing management. They want me to explain the benefits and the purpose of this experiment. They point to scrum books that say tasks should always be estimated in hours and a burn down chart can only be shown using hours. How do I convince management to allow the team to proceed with this experiment?
Read the full article…

Share it!

Should Engineers Take Scrum Product Owner Training?

Leave a reply

I was recently asked if engineers or other members of the scrum team would get value from a Certified Scrum Product Owner workshop.

Our Certified Scrum Product Owner workshops are designed to build knowledge and skill in three main areas:

  • How scrum works and how to use it effectively
  • How to build shared understanding of the requirements between stakeholders and the development team so the team builds the right thing
  • How to identify and focus the team’s efforts on the most valuable deliverables

These are topics every member of a high-performing team should be versed in. Having engineers participate in product owner training helps them understand the context within which they do their engineering work, and helps them understand how to interact better with product owners around topics such as the business value of paying down technical dept.

For products that are extremely technical, engineers usually work closely with the product owner in order to define and refine the user stories. If the engineers lack story writing skills, then the resulting ‘stories’ are often little more than a restating of the architecture and technical design. The problem with this is that many of these ‘technical stories’ need to be implemented before there is anything meaningful to the stakeholders. Once those engineers have been exposed to the story writing and splitting techniques in our workshop, they are better able to define/refine stories in such a way that they stay pertinent to stakeholders at all times.

I’ll also point out that all scrum masters should take the product owner training, as scrum masters are the scrum experts who provide guidance to the scrum team and the greater organization. Frequently, the scrum master will be called upon to coach the product owners in the various skills needed to be effective in product owner role.

Cheers,

Chris

Share it!

Scrum Sprints: How Long Should They Be?

1 Reply

HourglassHow long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.

Question

After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?

Answer

Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem, we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.

For your team, it is unlikely the underlying problem is not enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems:
Read the full article…

Share it!

Stabilization Sprints and Velocity

Leave a reply

Here is a question that just showed up in my in-box regarding how to calculate a scrum team’s velocity when they are doing stabilization sprints. This notion of stabilization sprints has become more popular lately, as they are included in SAFe (Scaled Agile Framework).

Question

We do a 2-week stabilization sprint every 4th sprint where we complete regression testing, etc. but don’t take any new stories. Is there a rule of thumb around including a stabilization sprint in the team’s velocity?

Answer

The purpose of tracking a scrum team’s velocity is to give stakeholders (and the team) predictability into the rate at which they will complete the planned deliverables (the stories). Velocity is the rate of delivery. The stabilization work doesn’t represent specific deliverables that the stakeholders have asked for; it is simply a cost that you are paying every 4th sprint, because you aren’t really done with the stories during the non-stabilization sprints.
Read the full article…

Share it!

Excuse me – Are you sprint ready?

2 Replies

Man sitting at the starting line taking a selfieA common complaint I hear from scrum teams: We didn’t finish all the stories we committed to deliver in the sprint. While there are many reasons for this, one often-overlooked one is: The user stories were not ready to enter the sprint in the first place. The solution is for the scrum team to decide which stories are sprint ready before the sprint planning meeting even starts.

The sprint ready vote typically happens during a backlog refinement session (AKA story time or product backlog grooming meeting). Sprint ready means the team is confident they can accomplish the story in one sprint. They have:

  • Confirmed and agreed on the acceptance criteria
  • Estimated the size
  • Confirmed all the story’s dependencies are complete
  • The story is small enough to be comfortably completed in a sprint (with all surrounding required processes)

I know this sounds amazing, even too good to be true. Think about how the chances of work being completed in one sprint would increase if all those aspects of story preparation were completed before the team started? I know – mind-blowing!

So how do you get there? A few small changes in story time and sprint planning make this possible.
Read the full article…

Share it!

Should Management Use Velocity as a Metric?

Leave a reply

Burning SpeedometerMany well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working or how much they are producing. Neither of these is correct. Velocity is a tool for predictability.

Because of this misunderstanding, many managers think that the team should work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Imagine that your manager wants to see the team’s velocity increase. This is very easy to achieve; the team can simply increase their story estimates over time. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule. What’s a scrum master to do?

Read the full article…

Share it!

A Scrum Master’s Perspective on Story Point Accounting

Leave a reply

Recently, I answered a question about how to do the story point accounting when a user story spans multiple sprints. The scrum team had several user stories that were started in sprint one, but completed in sprint two. Since velocity is a measure of the rate at which the team is delivering stories, we found it best to count all the points for a story in the sprint in which it is completed.

Now let’s examine the question from the point of view of a scrum master. A scrum master’s job is to help the team improve and progress toward the goal of becoming a continuously-improving, high-performing, self-organizing, possibly-over-hyphenated scrum team.

The question is being asked because the team members are feeling some pain. They have worked hard on four stories, but only completed one. This doesn’t feel good and they are looking for a way to alleviate the pain. The quick fix is an accounting trick to give the team ‘credit’ for working on, but not delivering, their stories. This only accommodates the team’s dysfunction. A scrum master will want to help the team find and fix the root causes of the pain. In this way, they may fix the problem instead of perpetuating it.
Read the full article…

Share it!

Dixit Sprint Retrospective Game

5 Replies

Dixit Game BoxI was inspired to create a retrospective game for agile teams, based on the game Dixit. Dixit is a game that makes use of picture cards. Each of these cards has an unusual drawing on it. The Agile Learning Labs team used it recently in one of our sprint retrospectives and it worked well. Give it a try with your team and leave a comment to let me know how it works for you.

Read the full article…

Share it!

Splitting User Stories with Timeline Analysis

3 Replies

This is the last of five installments in my series on splitting large user stories into smaller user stories. If your scrum team isn’t able to complete a minimum of four user stories every week, then start with the first installment and work your way back to this one. Occasionally, I find a user story that I cannot split using conjunctions, generic words, or acceptance criteria. When this happens, I use timeline analysis.

With this technique, I ask my stakeholder to pretend the user story is already done, and then I ask “What happens when the functionality gets used?” They will then describe a sequence of events. Even for things that happen non-deterministically, or which could happen in parallel, they still describe it sequentially; it’s just the way our brains and our language work. I then identify the verifiable steps in the timeline.
Read the full article…

Share it!