What’s the ideal Sprint length


I may have blogged about this previously. I have written so many blogs, I can’t recall any more. However questions regarding Sprint length surface on the forums regularly.

As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context – this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.

The Context

A team of 5 members currently working with 10-day sprints. They haven’t managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.

There is proposal to increase the sprint duration to 15 days “because doing review meetings and planning every 10 days is a lot of overhead” according to the team.

My thoughts

Let me start out by stating some facts …

The official Scrum sprint length is 30 days. However I don’t think (I don’t have facts to back me up on this but it’s the sense I get from all the communications on all the forums) there are many teams working to 30 days any more.

Much of the Agile community agrees that shorter Sprints are better. So 2 week Sprints and even 1 week Sprints are becoming more the norm.

Why are shorter Sprints better?

1. Well we have learned from the Lean folks that shorter Sprints means less work-in-progress which means shorter cycle times and overall less waste.

2. Additionally, shorter Sprints tends to stress your process, revealing any flaws. Like no automated build process, automated test harnesses our unit test frameworks. Fixing these flaws has a tendency to provide leaps in productivity gains for your organization.

So assuming you buy the argument that shorter Sprints are better. My initial quick answer to the question is don’t try to lengthen the Sprint. Rather try to figure out why you’re only hitting 60% – 70% of your originally committed goals.

By the way, 60% – 70% may not be that bad, after all you have a team that is currently demonstrating a consistent output Sprint after Sprint.

So that leads me to think that either the story point estimation is not consistent, or the team is just over-committing. So I would suggest that they do the following.

Try to really assess what is going on in the retrospective. Let team members speak freely about their thoughts on the matter.

I would definitely spend a little bit of time re-assessing the size of a few completed items i.e. if the story was 10 points originally, what would they estimate the size now, after the fact. Re-assessing the relative size may well fix the problem.

Some folks, most notably Ron Jefferies, would argue why do you need to get your estimation down pat. Well in my opinion for one, predictability goes a long way to help remove team stress. So its great for a team to say we can commit to say 100 points and deliver between 90 and 110 each Sprint. The business will love you for this.

Whats good about this problem in and of itself is that Scrum is doing what it’s supposed to do; surface issues for the team to resolve. And if the team feels that going to 15 day Sprints is the right thing to do, so be it – it might well be. But I would try to first figure out why 2 weeks is not cutting it. Many teams make it work so it should be doable.

Hope this helps if you’re in the same boat. If not at least if it provides food for thought!


Agile Project Management Questions Answered

Agile Project Management Questions Answered.I was asked recently to answer 5 questions about agile project management for a feature on PM Boulevard. I thought you might appreciate seeing them here too…

1. How has the Agile practice evolved over the last two years?

I don’t personally think that agile practices have particularly changed in the last two years, however there is clearly a stronger emphasis on some elements more than others now.

Scrum certainly seems to have crossed into the mainstream since I started my blog. Even though it was less than 3 years ago, Scrum still felt quite new and innovative in the UK at that time. I work in the web development sector and now every company I meet seems to be doing Scrum.

Another change is the interest in agile from the project management community. This seems significant as people start to think more about how best to apply agile on larger projects. Looking at Google Trends, which shows search volumes over time, the graph below shows that search demand for ‘agile project management’ started relatively late in terms of agile adoption, and interest is still growing strongly now.

The other thing that seems to be a clear trend during 2009 is a much stronger emphasis on Lean software development from the agile community. It seems to have really gathered pace in the last year or so.

2. What would you tell someone who thinks Agile is just another fad?

I don’t think agile can be called a fad now! Admittedly it may not be for everyone, but it’s certainly not a small minority any more. Again using Google Trends to gauge search demand and therefore people’s interest in a topic, ‘agile software development’ has been in high demand on Google as far back as 2005 (although it’s obviously been around a lot longer than that), and has remained high ever since. I don’t think something can be called a fad when the buzz has been going for over 5 years already and is continuing to grow strongly. For anyone that hates the idea of agile and is secretly hoping it might just go away, you’d better get used to it because I think it’s here to stay!

3. What are some tools that you use?

I know this might sound like it isn’t much help to others, but we don’t actually use any project management tools or any specific agile tools. Those who read my blog will know I’m a big fan of Excel and the whiteboard, although clearly agile project management tools would be a useful addition in some circumstances, particularly where teams or stakeholders are distributed across multiple locations or projects are particularly large.

In my experience, I’ve had several development teams practicing agile web development using Scrum, and they have been able to operate Scrum on a team-by-team basis without the need for any specialist tools to help manage. Instead we have placed a much stronger emphasis on face-to-face communication and collaboration, using Excel to manage product backlogs, user stories to convey requirements, and whiteboards to provide visibility.

4. Do you think that Agile and the PMBOK can coexist?

I definitely think agile and PMBOK can coexist, although some elements of PMBOK would be irrelevant to apply on an agile project. However there are plenty of elements of PMBOK that are not addressed at all within agile methodologies, for instance project initiation, cost management, risk management and various other aspects too.

I think the problem here is that a project manager must know PMBOK-style project management methods like PRINCE2 and agile methods such as Scrum very well to be able to choose the right techniques for the right situation. This obviously demands a lot of skill and experience from the project manager and is potentially very difficult for anyone new to either method. This is where experienced project managers that have successfully transitioned to agile have a really strong advantage over others who have only really managed projects with one approach or the other. It gives them the ability to blend the methods based on the unique characteristics of their particular situation, which along with leadership skills might be the thing that differentiates a good project manager from a great one.

I have blogged about this topic before here: Agile Project Management Is Not Enough!

5. Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now?

Apart from my own, I would recommend various other blogs, some of which you’ll find in the sidebar of my blog. My personal favourites at the moment are Leading Agile by Mike Cottmeyer, Succeeding with Agile by Mike Cohn, and Agile Techniques on InfoQ. In terms of books, you’ll also find some books I can recommend on my blog; they’re on an Amazon affiliate widget in the middle of each page. ‘Agile Project Management with Scrum’ by Ken Schwaber and ‘Agile Estimating and Planning’ by Mike Cohn are particularly recommended.


Photo by Marco Bellucci

Product Owner vs Product Manager


Based on a recent post on yahoo forums, seems like there may still be confusion out there as to what the differences are between these two roles. Questions like, is there overlap? can the Product Manager take on the responsibilities of the Product Owner? what are the specific requirements for either role? pop up all the time.

There was a really good discussion on the Scrum Development Yahoo group on this topic and some really good points were made. So I’ll try to distill this for you here and of course put my own twist on this.

I think that the founders of Scrum purposely chose a different title for a reason. They could have easily just kept the title the same. But I think there was good reason for this. And that is that the PO has a specific set of duties in the Scrum role.

How do their roles differ?

First and foremost is that the PO drives the priorities for the development team. This is done via the Product Backlog as a vehicle for communicating priorities. Essentially, a company has a certain available capacity to turn requirements into working functioning code. How that capacity is used up is completely in the hands of the PO.

In order for the PO to do this, the PO needs to understand the bigger picture. Whether or not the PO distills this information from other roles or whether he has to get this information himself depends on the company.

Based on his/her understanding of the bigger picture, there are some additional specific duties that the PO must perform (not necessarily defined anywhere):

1. Articulate the product vision to the team
2. Define the goals at the beginning of every sprint
3. Tell the story behind each user story so that the development team understands what is required. So the PO must understand the end user requirements.
4. Define or help define the user story acceptance criteria so the team knows when they are DONE
5. Be able to prioritize the stories and be able to negotiate/collaborate on priorities with the team. Negotiate priorities occurs when after taking the top priorities off the backlog; there may be some remaining capacity that the next highest priority story won’t fit in to. So in those cases, a lower priority feature could be picked.
6. Must be available at all inspect and adapt points to answer questions and help guide the team empirically

Product Managers on the other hand must be able to do a whole bunch of other things, including but not limited to:

1. Defining the marketing strategies and outbound marketing communications
2. Pricing strategies
3. Understanding the positioning of the product in the market place
4. Competitive analysis

A couple quotes from the forum worth repeating here

“Scrum does not prescribe further responsibility beyond optimizing development to ensure business success” (Anonymous)

“The Product Owner role, on the other hand, is really about representing the business side and working with engineering to optimize the software (or technology) delivery part of the entire product solution.” (Greg)

The best ..

“The product owner role is a genuinely new role and disruptive for most organisations, as it does not easily map onto existing roles and structures” (Roman)

In summary, depending on your situation, the PM and PO roles will be performed by the same person, a group of people or separate people – frankly I don’t care. As long as there is a person dedicated to doing the PO duties and responsibilities as defined in the 6 bullets above, then all is good from a scrum perspective.