I have two questions

1) How do you baseline project plan in Agile, How it is different from Waterfall

2) How do you calculate schedule variance in Agile

  • 2
    Could you give us a little more insight into what you're trying to accomplish? I'm sure there's a good answer, but to answer this directly, I would just be trying to tell you how to do waterfall things in Agile, which wouldn't end up very helpful.
    – Daniel
    Jan 24 '14 at 15:16
  • Daniel-My Organization moving towards Agile process and practices.Although Our understanding on Agile/scrum is more from theoretical perspective.In our case engineering team is trying this new process and Customers are still not yet ready for the process.From our side we want to get ball rolling as we understand the perceived benefits of Agile.In this context I would like to understand how to baseline for the project plan and also how should I identify schedule variance.In conventional PMO, schedule can be adjusted but in case of Agile it is the scope, so how to check for schedule variance
    – ramu
    Jan 25 '14 at 9:42

Your questions really hit at the heart of the difference between agile/scrum and waterfall style project management.

Scrum is less about command and control, and more about empowered teams that deliver "complete" features at the end of each and every sprint (a defined period of time). You only really plan (in detail) one sprint at a time, so there is no real need to produce an entire end-to-end project plan that is baselined and then changed (because we cannot accurately plan that far in advance). That does not mean that there is no planning in scrum, only that plans/decisions generally follow the "last responsible moment" principle of decision-making.

Rather than rewriting out the entire scrum approach (and putting it less eloquently than the professional authors), agile atlas was an excellent website an archived version can be found here

Here you can find an overview of the scrum approach that should hopefully reveal why your questions don't necessarily apply to scrum.

Hope that helps!

  • Gregg - Thanks for the response and also on sharing the agileatlas website for me to dig further. Based on your response I have a follow up question. I understand that in an ideal world, in a good agile process customer/product owner will be part of the team. In practical situations this is not always the case, atleast it is not yet fully put into practice in the context of my Organization. In this situation if I need to share the baseline to the Customer how to do (I need to understand this atleast till we have Customer part of the process) also how to track schedule variance
    – ramu
    Jan 25 '14 at 9:33
  • The agileatlas website is no longer available. An archived version can be found at web.archive.org/web/20161102003303/http://agileatlas.org:80 Jun 10 '20 at 12:37
  • The Scrum Guide at scrumguides.org/scrum-guide.html is a good starting point for learning about scrum. Jun 11 '20 at 13:19

Try the goal-oriented Agile Product Roadmap approach

Baselining can be done only when all the requirements are known in detail at the beginning of a project. And from the baseline you can calculate variances.

However, in Scrum you don't start with detailed requirements in advance. Here is the relevant quote from the Scrum Guide. "A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful."

As Gregg said, in Scrum you only plan in detail one sprint at a time. Then how do you manage stakeholders and coordinate the development, marketing, and sales activities? Here is the goal-oriented Agile Product Roadmap approach suggested by Roman Pichler. As he points out it "mitigates the conflict between viewing roadmap features as commitments and agile teams who only commit for next few weeks."


First and foremost stop mixing sprint(extreme programming) with iterations(Scrum). Sprints are 2-3 weeks, iterations are 30 days. Mix waterfall with Agile Scrum and Extreme programming (3 week sprints) in the following way.

Carry out your envisioning and planning the waterfall way producing work items the WBS way with a 8/80 rule. Prioritize the work items. Once you have your WBS, you can define your schedule baseline. Include you your design in the plan in process as

Next is development. Adopt Scrum. Create a definition of done. Add your work items as prioritized backlog items. Pick your work items during sprint planning and focus on completing at least one work item.

During sprint planning, have the team members(Dev, BA, Testers,etc.) add tasks and start development on 1,2,3 work items with focus on completing the top prioritized item (1). Monitor and control development - ScrumMaster. Within 2-3 iterations you will know your velocity. The burn down chart will spike up and then start going down for the rest of the sprints (if faster pace is needed).

Do Not Micro-manage. Do not assign tasks. Let the team define their tasks and pick them up.

Upper management is happy getting a schedule baseline. Development team is happy coding and completing.

Stop using the word "Agile". Just do it!

  • Do you think you could edit this and split it into paragraphs? That will make this both easier to read and more valuable to future visitors to this post.
    – jmort253
    Sep 16 '14 at 3:21
  • This doesn't seem to really attempt to answer the question that was asked. You just threw your vision of "the one true agile way" at OP with no justification and little explanation.
    – RubberDuck
    May 7 '16 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.