Skip to main content

Project Plan in Agile

Last post 11:38 pm August 9, 2023 by Thomas Owens
6 replies
11:32 am August 2, 2023

As per scrum guide, sprint backlog itself is the plan by the developers for them.  In that case, is it really necessary to create a separate project plan as we do in water fall model like activities, start date, end date, percentage of completion etc.


11:48 am August 2, 2023

If you have an ordered Product Backlog with clear, concise Product Backlog Items written in a way that is accessible to stakeholders, a clear expression of a Product Goal representing the current longer-term objective for the Scrum Team(s) working on the product, a Sprint Backlog showing a clear expression of a Sprint Goal and a plan for the team to achieve that goal, would any contents of a project plan add any more value for stakeholders?

I would say that many, but not all, contents of a typical project plan are either represented through the other Scrum artifacts or are unnecessary. That doesn't mean having some aspects of the team's way of working written down isn't helpful. A description of the team's implementation of Scrum, for example - when and where the Scrum events happen, duration of Sprints, the team's Definition of Done, where to go to find the most up-to-date Product Backlog, any additional documents or artifacts that are needed to make the product useful and usable and how those are maintained and distributed are a few examples of elements of a project plan that may still be useful in Scrum. Whether these live in a formal project plan or a more lightweight form depends on the context.


12:57 pm August 2, 2023

is it really necessary to create a separate project plan as we do in water fall model like activities, start date, end date, percentage of completion etc.

Usually, it is neither necessary nor wise to encourage fake certainty about such things. With complex work, it's better to offer evidence-based forecasts using measures such as velocity or throughput in conjunction with an emergent Product Backlog.


04:08 pm August 2, 2023

Why would you need the extra work of creating that plan for every Sprint?  If your Sprint Backlog is visible, you should be able to see the all of that information.  Percentage completed is determined each day during the Daily Scrum by the Developers for each item and for the entire Sprint. Start and end dates are defined by the Sprint timebox.  

Some teams will use burn-down or burn-up charts to get an idea of their progress. I personally don't like them unless you are "burning" the items themselves and not something like Story Points or estimates.  

During your studies of the Scrum Guide for the 5 certifications you have achieved, did you ever see anything that would indicate that such a project plan would be needed or even worth creating?


11:48 am August 9, 2023

In an audit context, I feel it is better to keep a formal project plan. 


02:57 pm August 9, 2023

Why?  If the audit is focused on how the work was done, the formal project plan would not be completely truthful because you would create it after the work was completed in order for it to be accurate. That would be a false representation. 

How often are audits done? Does your organization do regular audits of deliverables?  If the company is using Scrum broadly, their audit team should be aware of how the framework enables work to be done and audit appropriately.  If I were part of an audit team that was auditing an organization that claimed to be agile and used the Scrum framework, I would be suspicious if a formal project plan was presented to me. 


11:38 pm August 9, 2023

I agree very strongly with Daniel. I've spent a lot of time working in regulated industries as well as serving customers in regulated industries, which means a lot of audits. Although "project plans" are an example, I don't think I've explicitly been asked for a project plan. Instead, auditors have asked to see how we plan, how we monitor against the plan, and how we improve for future plans. In the context of the Scrum framework, the Product Backlog, Sprint Planning, the Sprint Backlog, the Sprint Review, and the Sprint Retrospective address their concerns quite well and don't require additional work to create documents beyond what the team needs to work in Scrum.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.