In Scrum, you develop product increments in short iterations called sprints. The sprint is a very central concept in Scrum: everything revolves around it.

In this post I talk about sprint length, preconditions for a successful sprint, and what to do when a sprint falters.

Each sprint starts with a planning event which I covered in an earlier post. The sprint ends with two other meetings: the sprint review and the sprint retrospective. Those will be covered later. These three events are part of the sprint, and make out the sprint boundaries.

Last time I wrote about sprint planning which is one of four formal events prescribed by Scrum.

In this post I explain what product backlog grooming is, when it is performed, and how it is done.

Backlog grooming is often performed throughout the sprint. Perhaps this is one reason why it’s not considered a formal event.

However, many teams do backlog grooming as an explicit meeting, and some people think it should be incorporated as a formal meeting in the guide, too.

Every sprint begins with a planning activity. This is when the Scrum team decides on the work to be done in the iteration ahead.

Sprint planning is divided into two parts.

During the first part user stories are analyzed, evaluated and estimated. After that, the developers determine a reasonable workload that they think they can commit to.

During the second part, selected stories are analyzed in more detail by the developers (remember, I use the term developer for everyone building the product, including coders, designers, testers, documenters, and so on).

“Time is what we want most, but what we use worst.” –William Penn.

Never is it more true than when it comes to estimating.

Indeed, to most people estimating effort is tightly coupled to time. How long will it take? When will it be ready?

This is futile: time is a moving target and calendar time, in particular, next to impossible to predict.

A better approach is to estimate the size, or complexity, of work, and to derive duration based on velocity.

The product backlog is the bucket from which you pull work. It’s a list of all items that potentially make it into the product. It’s the single source of requirements. That sounds easy enough. Perhaps it is, too. Yet sometimes it isn’t obvious what to put in the backlog, and how to select what items to work on next.

One challenge is to manage non-features such as technical items and bugs (in the rare case you have any, of course). People have different strategies to deal with the not-so-obvious stuff.

A common reason for disagreements is differing definitions. I once had a discussion with a friend about egoism and people’s ability to do truly altruistic acts. After an hour though, we suddenly couldn’t agree more. That was when we decided to define egoism.

Defining what done means is essential of exactly this reason. If you don't know what people mean by "done", how do you have meaningful conversations about progress and the state of work? How can you be confident when asking for estimates?

The agile team concept is one of the Scrum practices that might be difficult to fully grasp. For me at least,this is a continuous learning experience.

It is also one of the most important things to get right: and where many agile transitions go wrong. Cross-functional, self-organizing teams runs counter to the classical matrix management structure with project teams.

Many organizations do sprints, Scrum boards, burndowns, and so on, but don’t change their mindset much.

This is the third post in a series related to the Zen of Scrum presentation available on SlideShare.net.

In the previous post I wrote about Scrum's five values. Now it's time to list the roles, events and artifacts defined by Scrum.

Some of the things associated with Scrum is actually XP practices and not dictated by Scrum at all, though they have become de-facto standards and considered best practice by many.

While most people know about daily scrums, sprints and poker planning, and others only associate Scrum with post-its scattered on a whiteboard, few are aware of the five Scrum values. Do you know them?

This is the second post in a series related to the Zen of Scrum presentation (available on SlideShare.net). In the previous post I wrote about the agile manifesto where the five values are rooted.

To use Scrum, you arguably need to apply it wholly. However, some practices are not unique to Scrum: practices all teams can benefit from.

It might also be an eye-opener for people, making them more inclined to turn fully agile. I recently switched from a project doing Scrum to a team with no clear project methodology or framework: the change in the level of communication and willingness to change and improve was striking. I think these three things alone would go a long way to improve the situation.

Zen values simplicity, so does agile development. Zen means introspection, a key component of Scrum as well. Additionally, Zen is the attainment of enlightenment: very similar to the feeling when you first get agile.

As promised, here's the first post in a series about the free presentation Zen of Scrum available at SlideShare.net. (It is also available as PDF here.)

Why did I name the slideshow Zen of Scrum¹? In addition to the things mentioned above, Zen is a state of complete awareness where you are in perfect tune with your surroundings, ready for anything. This is a goal of Scrum, too: you should always be prepared for, and welcome, changes.

The final article in the series about the Pomodoro Technique® and Scrum covers objective VI: Other Possible Objectives which, I admit, is a bit fuzzy.

One goal of Scrum is to continuously improve. This is formalized in the sprint retrospective. Identifying and implementing potential improvements is part of the agenda, and second nature to agile practitioners.

People might not like the idea of Scrum for many reasons. Three types of teams that don’t Scrum though they might have heard of it are:

1. Teams that are productive
2. Teams that think they are productive
3. Teams that don't want to be productive.

So before shifting to Scrum, think about your reasons behind migrating and if it is a good idea to start with. If you go through with it, consider how teams will react to the change and formulate a transition plan accordingly.

This post is about the Pomodoro Technique® objective V: Set up a timetable. Instead of writing about how setting up a timetable and respecting work hours helps you keep a sustainable pace and uphold productivity (curiously enough a key XP practice as well :-)), I will focus on the similarities between objective V and a Scrum Sprint.

I think it's striking how well the fifth Pomodoro objective correspond to the essence of iterative development and Sprints.

Having started with the Pomodoro Technique® and seen how it can help you focus by cutting down on interruptions and improve estimations, it is now time to get the most out of each Pomodoro: Make the Pomodoro More Effective.

A big part of making the Pomodoro more effective is to think about how you structure and apply Pomodoros. It can also involve introducing dedicated Pomodoros for specific subtasks, and splitting work into meaningful subtasks.

I have uploaded a presentation to slideshare.net, and you’re welcome to download it for free. It is also available as PDF here.

I plan to follow it up with a series of related posts. Stay tuned!

In six posts, I have written about agile roadblocks: obstructions for implementing agile processes. The time has come to conclude the series with a summary and a couple of final words.

The theme of the series has been issues you might be facing when migrating to agile development.

Agile principles are easy to understand but can be difficult to master, and the transition to agile can be as complex as the problems it tries to solve.

This is the third post in a series about applying the Pomodoro Technique® to Scrum and for development.

Each post covers one of the Pomodoro Technique® objectives. The third objective is to Estimate the Effort for Activities.

All developers are used to giving estimates. Most developers are also aware of the problems related to giving accurate estimates. Especially, providing an estimate in calendar time can prove difficult, not to say impossible. Pomodoros offer an alternative approach that works very well with Scrum.

Scrum and Getting Things Done (GTD) are two frameworks developed with one common goal: Increase productivity.

Scrum and GTD have very different premises: Scrum is a project management framework, while GTD is a “work-life management system”. Scrum is all about the team. GTD is based around the individual.

Despite the apparent differences, Scrum and GTD have much in common. They base their success on some fundamental observations on how to become productive.

In the series about agile roadblocks: obstructions for implementing agile processes, the time has come to “Cross-Functional or Dysfunctional”.

Cross-functionality leads to autonomous teams where complete features can be developed independently. One roadblock to achieve cross-functional teams is organizational silos¹. Another potential problem is the common misconception that individuals need to be cross-functional.