Scrum Myths: There is No Planning in Scrum

Exactly I could not agree more. Often companies what detailed plans for the next three years. Plans get out of date so fast.

Right on, Barry. Keep it lightweight and frequently inspect and adapt.

Even creating and locking in those three-month plans is too much. I've experienced "Agile Coaches" and "Scrum Masters" who still teach and breed these top down, long range, overly defined plans usually conceived by the "Product Owner" (who is really a Project Manager). The root cause analysis always leads back to a lack or complete misunderstanding of the manifesto and the Scrum framework.

I understand your point and I agree that waste is limited when only focusing on planning work for upcoming sprints. But how do you deal for example with an epic list for 2017 from the management team? If you only refine epics for upcoming sprints, it is not possible to give a forecast for coming 3 to 6 months.

You absolutely have a backlog beyond a single Sprint, but also keep learning and evolving it as you learn, you change. Inspect and Adapt... If you execute what you thought was right 6 months ago in 6 months, you may be wrong in what you execute or the priority of it. So, always have the roadmap, but be willing to change and evolve it.

A plan for a sprint is not "planning." It's just keeping your job for another few weeks.

Help! :)

Situation: Multimillion EUR project; +10 teams; certain date that project needs to be finished. Major delivery is a new platform.

1.) How do you estimate overall time / costs? Or do you just estimate sprint?
2.) What should be done in the first sprint? Hardly anything can be delivered without the platform, everything is integrated.
3.) Which team should be picked up first? You can start the project from multiple sides, unless most of the teams deliveres, there will be nothing working.
4.) HW delivery is up to 8 weeks however at the beginning it is not clear which one should be chosen.

Thanks a lot,

I cant imagine any management would say. OK, go on, start and lets see how much it costs and when u r going to finish.

This won't help much as the comment is 7 months ago as of this response's writing. But commenting for the sake of discussion and future reference.

1. Overall time/costs can be forecasted with rough estimation, having a benchmark project. This will have many factors affecting it, and it is highly important to communicate the risks and effects to the project cost to the upper management. A range of minimum, maximum, and highly likely cost can be provided, with outlined rationale and risks for minimum and maximum.

2. A question that can be asked is whether there is a slice of the platform that can be shippable? Does the platform really require the whole integration? If so, can there be at least one small function or feature that can be included in the sprint together with the platform? First sprint usually takes on architecture, schema, and major discussions among the scrum team members. This is usually also a good avenue for the Development Team to stretch and challenge the situation whether there really is no possible way to deliver a prototype.

3. What if there is an advance team that is cross-functional (knows all sides of the platform as one team and can deliver a prototype)? They can work on smaller scale and then when the prototype is successful, scale up.

4. (not quite sure what this means).

On this web page, just under the text "We just plan differently to optimize effectiveness." it appears that maybe there was intended to be an image, but it is not displayed. Maybe someone could check this?

Just to signalize: planning in scrum picture doesn't work

The question is why do you need multiple sprint planning at all? The daily stand-up is a small planning meeting.
But if you mean going through the backlog for refinement, well this should be a continuous activity. You can use any method you deem effective to do the job.
If you mean release and delivery planning, technically these are not sprint planning. You chose whatever method to do it.
The spring planning is really meant to plan for the sprint to come. If you need more than one because you do not have time to finish the planning in one meeting, it's probably because your backlog items are not refined, the PO has done a poor job, or your team is too big.

1. Having multimillion EUR of approved budget doesn't mean you have to spend it all right away by having 10+ teams at the word go.
2. Similarly, having a certain date to finish, does not mean it has to be a big bang release for end customers.
3. With #1 & #2 in perspective, can we start with just a simple experiment - testing simple hypothesis of whether or not customers really want what you are trying to build with multimillion budget and so many folks
4. Once hypothesis is validated and learning is achieved with the experiment in #3, it's time to prioritise the backlog and pick the most important (valuable) thing you can do (this could also be clubbed with experiment in #3 to find out from end customers directly what would they want to see first)
5. Once prioritized, figure out what's the LEAST team size (could be multiple scrum teams) you'd need to run experiment#2 i.e. to validate that what you prioritized is indeed valid and that you created it right.
6. Learn from this experiment, re-prioritise, re-estimate, re-plan and gradually increase the team (only if needed) sufficient enough to keep delivering value at regular cadence (read sprint). Keep repeating the loop

NOTE: delivering the project (as though about in past), spending multi million EUR in fixed time MAY NOT yield any value.
BUT ensuring value is delivered with every small step you take with small investment (money, people, time) is going to return way more ROI (returns on investments).

Keep experimenting keep learning and keep delivering value fast and frequently!

Plan and Planning!!! Great!!!

I reply even late because I am really interested in this thread. I would like to clarify the questions of Nikola because I understand perfectly the problem.
First the non technical part: most of my customers (and also gouvernment projects) want EXACTLY this: a contract where you write:
1) amount to pay
2) exact date of shipping (yes it is a big bang release, I repeat: they want a big bang release)
3) detailed specs document where each functions of the software is present eventually with mockups.

The other interesting points are 2 and 3 on what to do in first sprints. The idea is: is Scrum forcing application architecture? Do I need to implement only microservices based application to comply with Scrum rule to do something shippable at every sprint? Can I design all my database in advance with scrum or I need to do it one table a sprint and refactor it sooo many times?

I can only agree with the content of this post. Yet how do you manage the expectations of your executive management?
The business pushes the product owner (who is often the product manager) to commit on upcoming release dates.

Great article. Great phrasing.