Take the 2-minute tour ×

I'm new to scrum and using it on a project. We do 3 week iterations, estimate at the beginning and then collect the points at the end.

We have a product back log (probably not complete).

If you do estimates of the entire back log at the beginning aren't those estimate just 'wild ass guesses'

So when do you estimate the back log and how do you determine a release date?


share|improve this question
What do you mean by "collect the points at the end"? –  Thomas Owens Sep 9 '11 at 19:16
@Thomas Owens: Story points for built (but not released) functionality. –  S.Lott Sep 9 '11 at 19:34
@S.Lott OK. I'm familiar with that activity, but I just didn't remember that phrasing. Is that what it's actually called? –  Thomas Owens Sep 9 '11 at 19:55
@Thomas Ownens: Self-organizing teams means picking terminology that makes the team happy. –  S.Lott Sep 9 '11 at 19:58
add comment

4 Answers




You have periodic release sprints in and among your build sprints.

Don't wait.

Put software in the hands of users as early and often as possible.

In principle, each sprint leads to something that could be released to users.

If your sprints aren't releasable, you're planning them poorly.

You should consider that each sprint is eligible for demonstration or acceptance testing. And you should release more often than once at the very end.

At some point, you'll have a release which users really like and backlog that's non-zero, but so low-value that the product owner decides that no more active development sprints are needed.

In one sense, you're done. Users are happy.

In another sense, you're not done. Backlog is not empty.

This point is very, very difficult to foresee, but is the most important part of Agile methods. You've created enough value and avoided wasting time on low-value elements of the original vision.

share|improve this answer
I think this comment demonstrates one of the issues with using Scrum if the larger organization doesn't also use Scrum: You then have to create estimates about how many sprints you will need to eat through your current backlog and any items that will be added in the future, or you likely won't mesh with the larger organization's desire for longer-term timelines. It can be done (and, IMO, is often worth doing), but it is a real problem that needs to be resolved. –  Ethel Evans Sep 9 '11 at 23:40
add comment

Our approach is that, we tend to guess required time only roughly at the planning meeting. This gives product owner a feel of how much a PBI would cost. He then prioritizes items based on this, and he defines some milestones. I think those milestones are releases.

For example, we work for 3 sprints, and while we deliver working products at the end of each sprint, only after 3 sprints we release our product to the end users. Then after another 4 sprints we deliver the second part of the product.

I think it depends on the user, and delivery mechanism. For example, if your product is something like Microsoft Office, then you should deliver the entire applications (Word, Excel, Access, PowerPoint, etc.) in a package to the end users. This means that release date should be the date when all of the applications are ready. But, you may release Word separately from Excel, to your stakeholder or to an internal user. This means that release date for you is when you deliver Word, but release date for sales manager would be when he/she can sell the product in the market.

share|improve this answer
Actually, if your product is something like MS Office, you should still release it in pieces. MS Word, specifically, has so many features that almost no single human being can understand it. It's really several simpler programs struggling to be free. I wouldn't include the "entire applications ... in a package" part because I think that's a mistake. –  S.Lott Sep 9 '11 at 19:06
Yeah @S.Lott. I understand that. We offered our CMS first (after almost 4 sprints), then we offered our SEO plugin (after 1 sprint), then a portal for customers to manage their multiple CMSs (after another 3 sprints). I agree. –  Saeed Neamati Sep 9 '11 at 19:09
@S.Lott - I'm not sure Microsoft's Marketing department is quite so agile. At some point they're going to want to charge for all those little releases. –  JeffO Sep 9 '11 at 19:36
@Jeff O: Don't we get "patch" releases all the time? –  S.Lott Sep 9 '11 at 19:50
add comment

According to the Scrum Guide,

Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog... Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team... Grooming usually consumes no more than 10% of the capacity of the Development Team.

So you should be working with the Product Owner to add detail and estimates to your Product Backlog items throughout the Sprint, not just during Sprint Planning, which should concentrate more on planning your goal for the current Sprint. Estimates for fuzzy items should be large, because of the uncertainty involved. As you get more feedback from customers, discussion with the Product Owner, etc., you can improve your estimates.

At the end of a Sprint, the new Increment must be "Done,"... It must be in usable condition regardless of whether the Product Owner decides to actually release it.

So, it's up to the Product Owner when it gets released. He may decide he wants to wait until some specific set of high-priority features has been included in the Increment, or he may have a fixed release date at which point whatever is Done gets released. In any case, whatever the Team delivers at the end of a Sprint should be ready to ship to customers, so that the Product Owner is free to make that decision.

Since the Product Backlog is ordered, the Product Owner can also use the Team's velocity to make an estimate of what Product Backlog items will be Done by the end of a given Sprint. He may thus plan a release date well ahead of time based on when he feels his set of high-priority features will be done, or he may order features in such a way that whatever is needed for a given release will be done by the time that release date rolls around.

Note that early in a project, a Team's velocity will likely be all over the place as they nail down their Definition of "Done" and possibly take out some early-project technical debt, so it's hard to make these kinds of projections. If you need to determine release dates at an early stage, it's probably better to set fixed release milestones, or to just wait until the outcome of a Sprint is deemed to contain enough value to be released.

share|improve this answer
+1 Velocity is, IMO, the key concept to answering this question. The milestones idea is a good one for if upper management just can't wait until a realistic velocity can be established. –  Ethel Evans Sep 9 '11 at 23:43
add comment

In theory each sprint should result in product increment which can be released. The question is what does release mean in this case? It definitely means that the released increment should be available for some group of users to use it and get feedback but it doesn't have to mean that you have to do a big production release every two or three weeks.


Suppose that you are building some larger application which should be available publicly. Product owner has some idea what is minimal feature set needed to make the application available publicly - without these features users will not like the application and it will hurt company reputation. So the first public release is based on availability of these mandatory features. During development of this first public release team can still release every sprint but those incremental releases will be available only internally within company and company employees will use the application all the time during the development.

The public release date can be defined as well. Team's progress and velocity will show if the team is able to deliver necessary features to that release date early in development stage. It will allow product owner and management reacting on this soon enough if it will be obvious that requested feature set is much bigger than deliverable feature set.

share|improve this answer
add comment

Your Answer


