Sprint planning

In the iron triangle of project management there are three variables: scope, time and cost.  Predictive methods (i.e waterfall) fix scope up front and try to predict time and cost.  We know that usually doesn't work with software projects.  With Agile the adaptive frameworks typically fix time and cost, and make scope variable.  So to answer your question, fixed scope is not Agile.

Think of every Sprint as a mini project.  There's nothing wrong with having a plan, as long as the Scrum Team can "respond to change" after every Sprint based on new evidence and facts.  You're correct, inspecting the Increment at every Sprint Review and then collaborating with stakeholders on the next best Product Backlog items to work on next Sprint is empiricism, which is part of Scrum.

There's an old saying, "Plans are worthless, planning is everything".  I have seen Product Owners develop a roadmap, with potential forecasted release dates.  Nothing wrong with it if they can adapt their roadmap and release plan.

A Product Owner can make a delivery forecast for as many months or years in advance as there is empirical evidence to support it. This can include strategic and release plans and roadmaps, any of which may be forecast in the Product Backlog. A forecast however is not the same thing as a commitment to a goal.

A commitment to a Sprint Goal, for example, ought to be made on a Sprint-by-Sprint basis, such goals being framed and agreed by the whole Scrum Team in Sprint Planning.

Note that the delivery of a “component” is unlikely to represent a satisfactory Sprint outcome unless it also constitutes a valuable and usable feature of release quality.

Appreciate the responses. In my view, and understanding of agile, we can set a sprint to take 2 weeks, agree it’s going to have 5 developers (for example), but then the fundamental output of that sprint cannot be decided way up front unless - as Ian says - there is fundamental evidence to support we can do this, which there isn’t in this case.

I honestly believe that if a project has a fixed scope and time to deliver (eg we use deliver X piece of software, with defined functionality by a certain date), then accepting a Waterfall approach is better. For sure, we can incorporate some Agile concepts but the project is still fundamentally Waterfall.

As Chris says:

fixed scope: Waterfall

fixed time: Agile

Would you agree?

In answering this, I'm assuming that each component is its own "Done" piece of working software within a product, and can be used to gain feedback in some way.

If a component is something that cannot work without the later components, then perhaps it doesn't meet the definition of "Done", or maybe the definition of "Done" is inadequate.

Once an increment comes from Sprint 1, will that be used to empirically decide what is done next?

Irrespective of whether the forecast of completing Component A in Sprint 1 turned out to be correct, valid decisions could include:

• Continue with the plan to complete components A, B, and C, and confirm that the original forecast appears correct
• Adjust the forecast for when components A, B, and C will be done
• Change the scope of the components, to accommodate completion dates
• Adapt the Product Backlog and work on a different initiative in Sprint 2
• Cease development on the product, because it no longer looks like it is a good investment

Thanks Simon! 

Component A, Component B are iterations of working software, however I would question if this approach is really Agile since we are determining exactly what we are delivering up front and when. This sounds like Waterfall to me.

and, not that there is anything necessarily wrong with Waterfall for certain projects (requirements unlikely to change and so forth) 

The agile manifesto mentions:

Responding to change over following a plan

So it states there can be value in doing both, but more value in responding to change.

Is there a desire to know when the original plan has proved to be imperfect? Is there a desire to follow a different plan when new things are learned?

If the answer to either one is no, then agile is perhaps not the way to go.

Thank you, what do you think to my statement that the idea is not really agile since the scope and time are fixed, therefore it is more iterative Waterfall?

Well, isn't Scrum an iterative waterfall anyway? A sprint-long one? You start with sprint backlog and plan how to make the sprint goal happen (requirements), then you execute, inspecting and adapting everyday, and at the end you hopefully deliver, and stakeholders evaluate, plus post-mortem (retrospective).

This is the whole idea of Scrum: you take fluffy, nice-sounding but imprecise and not easy to achieve agile, and put it in a body armor called Scrum. Yes, the body armor limits your movement (during iteration there is a constant focus on non-changing sprint goal -> less agile!), but it also shields the team from external adverse stuff, like ever-changing scope, and protects organisation by limiting risk to just one iteration.

"the scope and time are fixed" - devil's in the detail. How fixed is the scope? "Component A, Component B are iterations of working software" - if after doing component A and B there is inspection and possible adaptation of the plan, then having a plan in the first place does not imply this is not agile. I used to work in projects, where there was a plan for dozens of sprints ahead, but there was still A LOT of inspection and adaption, as not every details was know from the start. We were happy if the plan worked, but we made sure it was not set in stone, as problem was complex and not totally predictable.

There are Scrum scaling strategies like SAFe that attempt to "map out" 4 sprints at a time.   Keep in mind that, as Ian mentioned, this is a forecast/roadmap, and not a hard and fast plan.   As long as you can pivot in between sprints based on empirical evidence and feedback, you can work under the Scrum framework.

@ Chris, there is also a 4th leg of the "triangle" (quality), which is fixed under Scrum, but variable in a waterfall approach.   And I believe it was Patton who coined that phrase about planning being essential but plans being useless, which makes perfect sense if you think of software development in terms of a military campaign.   You can try to plan as much as possible up front, but when you launch your troops, you also need the ability to adjust on the fly based on what you see and experience.

Ok I may be off my rocker but you said Sprint 1 goes to the end of June, Sprint 2 goes the Middle of June, Sprint 3 goes to the End of June; is this a typo or do you have 3 sprints overlapping? 

The purpose of Agile, according to the Scrum guides I have read, is to deliver working software at the end of each sprint 

No. The goal is not to deliver working software at the end of each sprint. The goal is to develop releasable working software by the end of the sprint. You can go 3, 4, or 8 sprints without releasing software if that is what makes sense for the product and the best way to get the ROI and value. 

I would question if this approach is really Agile since we are determining exactly what we are delivering up front and when. This sounds like Waterfall to me.

The core difference between Agile and Waterfall is not planning. It is the continuous loop of feedback from stakeholders, inspecting and adapting to feedback and other components, constant improvement, and working in a way that will provide ROI and Value sooner. In most cases, waterfall incorporates stakeholders at the beginning when they decide what they want and at the end when they receive what was developed. Barring a major change that is required, there is no feedback loop from the stakeholders; they order something, dev team creates it and it is released to the stakeholder. In Agile, however, they are involved frequently throughout the process and therefore they are able to receive a product that will benefit them to a greater extent. Say a product is ordered that will take 9 months to create and deliver. 9 months is a long time and the market can change, customer base can change, technology definitely changes. So using Waterfall, the stakeholders agree on a product and don't see it until it's done 9 months later. When they get it, they realize much of what they got doesn't apply to their customers anymore or is outdated because of the creation of a competitor's product. All that time and resources are wasted. Now using Agile, the same product is forecasted to take about 9 months to create. Stakeholders get to see the progress through each sprint so they are aware of the market changes and can request updates as needed. Say during the review of sprint 4, the stakeholders realize there was a drastic change in their competition and/or customer base that makes a portion of the product obsolete and therefore changes to the product are required. Thanks to Agile, that can easily be done early in the development cycle, sure the final product completion date will likely be changed but the end result will be what the customer/stakeholders actually need.