How do you schedule delivery dates in Scrum?

Question

I've run into a constant issue. When a project starts, the client typically has a list of functionalities to be built in to the application. As a team we would like to follow Scrum. But the next thing the client asks is for a go-live date.

The client has his own deadlines to go to the market. So it's valid that he needs to know a date so that he can tell the rest of the business when the application arrives.

Since the team can't plan out more than one sprint at a time, there is typically no visibility on the end date. The client says, "I've already told you exactly what functionality I need. Tell me when you can build this app."

How do you deal with a situation like this in agile or Scrum?

Answer 1

TL; DR

Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, but can be a political one in non-agile shops.

How to Perform Agile Release Planning

Agile release planning is based on iterations. In order to do calendar- or time-based release planning in Scrum:

1. The entire Product Backlog is given a rough estimate, usually at the level of epics rather than detailed user stories.
2. A fixed Sprint length is determined. 2-4 weeks are common values; this length should not change during the lifecycle of the project without recalculating Sprint capacity and adjusting release schedules.
3. A velocity is calculated based on the team's past performance, or on an "educated guess" if no past performance is yet available.
4. A fudge factor for the cone of uncertainty is applied. This is commonly 0.6 for new teams or for projects with large cones of uncertainty during initial project planning, but fudge factors are inherently variable and can be adjusted to fit currently-available knowledge about the problem domain, the team, and available resources.
5. A planning velocity is calculated, e.g. estimated velocity * fudge factor.

6. Number of iterations for a release are calculated using the following variables and formula:

   • e = aggregate estimate of all Product Backlog Items
   • v = planning velocity
   • i = estimated iterations for release, rounded up to nearest whole number
   • e / v = i

7. The i value can be turned back into a calendar or time estimate by multiplying interations by the length of the Sprints in weeks or months, e.g. i * 2.

A Worked Example

Let's say you have a total backlog of 200 story points, and plan to use a two-week Sprint length. Your team's historical velocity is 20, but this is a brand-new project with a large cone of uncertainty, so your fudge factor is the standard 0.6 multiplier; as a result, your planning velocity is 12 story points per Sprint after applying the fudge factor.

So, your release plan for all of the Product Backlog Items would be:

200 / 12 = 17 Sprints

You then turn this into a calendar or time estimate with:

17 * 2 = 34 weeks

Based on this information, your project schedule will state that it will take approximately 34 weeks to ship all the features currently in the Product Backlog. This is an estimate based on the information currently available, and should be treated as a planning value rather than an ironclad guarantee.

Adjust Scope During Inspect-and-Adapt Inflection Points

As the project progresses, the cone of uncertainty narrows and the team can make more accurate estimates about the amount of remaining work on the Product Backlog. In addition, a properly-functioning Scrum team will become more accurate about measuring its velocity as the project continues, so the release-schedule calculations should be redone from time to time to "true up" the schedule based on more accurate data as it becomes available.

In addition, the Product Owner may add or remove scope (in the form of Product Backlog Items) throughout the project. This will expand or reduce the scope of the project, and will obviously impact the estimated schedule. Changing project scope should generally trigger a recalculation of the release date when that happens.

Finally, Scrum strives to provide a potentially-shippable product at the end of each and every Sprint. While it may not be feature-complete in the sense that it contains 100% of all backlog items, the product should be a stable and releasable state during Sprint Review so that the organization can choose to ship earlier if sufficient value is present in the product to justify shipping in its current state. This "cashing out" of earned value to ship a minimum viable product that is deemed "good enough" can provide the business (not just the Scrum team) with a significant agile advantage.

Answer 2

You have historical data about your team

The only tool you have in Scrum to help this situation is your velocity. I believe you know your velocity - how many story points you do in a sprint -, check the product backlog and do planning on each user story. Using these two, you'll have an estimation on a possible delivery date.

delivery in weeks = ((number of point in backlog) * (number of weeks of a sprint)) 
   / velocity

This is highly inaccurate, but based on what you have that's all you can do.

If you have a product owner (PO), he/she should negotiate the deliveries with the customer based on your progress and delivered user stories. The PO should figure out which user stories are must for your customer to start his business. It is a subset of the whole product backlog, and therefore the formula above should provide a better estimate, because the uncertainty is lower than for the whole backlog.

Alternative one, you can check your historical data and see how long did it take to deliver a similar app, check the risks you see and provide an estimation using this.

time to deliver the previous app + 
   sum(additional length of each risk when they happen)

Alternative two, you can try the way Kanban handles these situations: http://zsoltfabok.com/blog/2013/02/when-will-it-be-done/

You do not have historical data about your team

In case you don't know the velocity and has no historical data, you can try to talk to your customer and figure out which are the most crucial features. Sit down with your team and estimate the project in the old fashioned way.

In the mean time, you can try to show the benefits of continuous delivery to your customer. Frequent talking and continuous delivery is the key to Agile, I recommend to start with them + the initial estimate. If you customer understands them and the benefits - frequent deliveries are very helpful when one schedules upstream projects -, it is going to be a win-win.

Answer 3

Zsolt has some good starters, I'm giving him a vote up.

Scrum works very well for fixed release dates so long as you recognized a simple reality. That being with Scrum you can have one of two truths.

1- You either get all the work in the backlog done. You just don't know when.

2- You release on a specific date with the work you've managed to complete by that date.

If your client (or internal boss) gives you a fixed date then you have to ship on, then you use techniques like what Zsolt talks about and estimate how much work you can do. At the start of development my general guideline is you don't commit to more than 50% of what you think you can do. This is because Hofstadter's law stats you will always underestimate the work to do, even when you take the law into account.

Then, the joy of Scrum is as you move through the project, you will be able to use your velocity to refine your prediction of what you will deliver. By the time you are 2/3 of the way through development, you will have a rock solid idea of what will be shipped.

This means you need to make sure the backlog is well ordered. Deliver the most important stuff first then the minor stuff. So if you don't ship everything, it's you are not missing the MVP stuff.

If your client says "But it all must ship", you have a different problem. Scrum won't fix that, you need to take agile up the value chain. I recommend Innovation Games Prune the Product Tree and Buy a Feature if faced with this.

Note: One thing I noticed in your post is you mentioned "Since the team can't plan out more than one sprint at a time". This is a flag for me. Teams should be working outside the normal sprint with their product owner to groom the backlog and plan future work. By the time you get to a sprint, you should already have a good idea of what you will be doing in the sprint. I've got one team that just worked with their Product Owner and have a working plan (it will change) for the next eight sprints (4 months). A separate topic from this one, just something I wanted to bring to your thinking.

Answer 4

The idea of Scrum is for a team to focus on delivering what a customer wants. To do this we do some work, demonstrate it, listen to feedback and then adapt. This approach recognises that it is hard for a customer to get their requirements spot on up front. It is much easier to build a successful product when you have constant feedback and adaptation.

If a client wants to fix the scope and the end date of the project then they will not get the full benefit of the Scrum approach.

I would suggest talking to your clients and selling them on the idea that the Scrum approach gives them the chance to shape the product to what they want. There will be some uncertainty about the end date, but this is offset against the value of getting the product right.

Of course there will be some situations where the client has a hard deadline. In those situations we work down the prioritised backlog of requirements as far as we can in the time allowed. If the client introduces new requirements as the project proceeds it may reduce how far down the list you get. In effect what is delivered and when it is delivered will be driven as much by the customer as by the delivery team.

Answer 5

There are two methods of forecasting delivery dates for your backlog:

1. Reliable Scrum.
2. Throughput Forecasting.

Reliable Scrum

Is very similar to what Todd is describing in his answer, but more accurate, because:

• it forecasts your end-date not just by average historical velocity, but takes into account its deviance -- because velocity will jump up-down from one sprint to another.
• it similarly takes into account statistics of how many new User Stories are added to your backlog by Product Owner -- and it can dramatically affect your delivery dates!

So, go by the link below, watch the video and download Excel file which does the math for you -- all you need is just to put your backlog items in it, their estimates and in which sprint they are completed or added.

Throughput Forecasting

Is a technique, when you even don't need estimates for items in your backlog -- you just put "1" as estimates in your Reliable Scrum file for all User Stories in it, and then you get accurate forecast of when your backlog will be completed.

It seems like magic, but actually works very well, because it, in fact, takes into account fact time needed to complete your work items. I.e. it is not affected by noise from non-accurate expert estimates of your backlog items!

When I compared both methods on 5 projects, it shown that both methods work very well, and the last one produces even more accurate results than the first one.

For more information, please, see Troy Magennis video. You don't need to understand the theory behind -- just know, that using Reliable Scrum with "1" as estimates for your backlog items works very well.

Answer 6

I believe it is this kind of historical situation that led to the Agile value

customer collaboration over contract negotiation

Also take of note of

responding to change over following a plan

The PO has a customer engagement problem which they need to solve before work can start to avoid an expensive mess.

Father of Scrum Jeff Sutherland devised a Scrum pattern, 'Change For Free and Money for Nothing'. While it is unlikely your organisation or customers are ready to sign up to such Agile contracts, it is worth reviewing these to understand how the PO should be engaging with customer optimse value and ROI.

Answer 7

Use buffered Moscow rules

http://mse.isri.cmu.edu/software-engineering/documents/faculty-publications/miranda/mirandabufferedmoscowrules2.pdf

Regards,