Baselining project plan and schedule variance in Agile

Question

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

Answer 1

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!

Answer 2

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."

Answer 3

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!