Estimation of project duration on Adaptive methodology

Question

There are 2 ways to predict the duration of the tasks in a project. The first is by using a Gannt chart like the one bellow for the Predictive methodology (Waterfall approach):

The second way is the Adaptive sprint schedule:

What I don't understand with the Adaptive sprint schedule is, shouldn't the individual sprints contain specific tasks? For example, in the picture for Sprint 1 it has tasks like 'Sprint 1 Planning', 'Sprint 1 Development', etc. Shouldn't instead of these tasks be like 'Account Login Planning', 'Forgotten Password Planning', this/that planning/development etc.?

How can someone predict the full duration of the project and the tasks that will finish in each sprint if the sprints do not contain specific tasks?

Answer 1

I think that your second image is a template that you should use to plan out your Sprints. Where did you get the image?

You do a longer release planning with Scrum by:

• organizing your backlog with proper priorities for the items;
• do a rough estimate of the backlog items;
• then using your team velocity and known duration of a sprint, try to figure out how many sprints you will need to run through all of the backlog items.

The approach is already described on the site, for example here: How do you schedule delivery dates in Scrum?

So yes, your project sprint schedule should contain backlog items in each sprint. You say "tasks", but tasks are too fine-grained for that. Most likely you will have epics that you sized against one another then figured out which ones you could stick into which sprints.

Now, as others have pointed out, this doesn't mean that your estimate and your planning will actually happen. If you planned something in sprint 6, starting on 10 October, it doesn't mean that it will happen and you will actually work on it. And this isn't a problem with Scrum or an adaptive methodology; this is a problem with the nature of software development and estimates. Estimates are forecasts, not promises, and not commitments, because things can change with time.

For example, the things that can happen with your planned sprints can be this:

• you estimate and plan out your features by fitting them nicely into sprint boxes;
• in sprint 1 you should work on X;
• in sprint 2 you should work on Y;
• ...
• in sprint 6 you should work on Z;

So far, this planning isn't any different than Waterfall or a predictive approach. The difference is that in Waterfall for example, you start working on the features and at the end of the project you show everything to the customer, or at (large still) milestones at best. And the customer doesn't like it, or finds the application unusable, or doesn't solve the full problem, etc. Why? Because at the beginning of the project you know the least about the project. So all your planning, schedule, and Gantt charts will probably be just a high dose of wishful thinking built on unknowns and assumptions (including the assumption that things won't change or deviate from plan). Agile, instead, recognizes these problems and the fact that things will change.

So what happens in something like Scrum, instead? Well, you do sprint 1 and work on X. You show X to the client and client is satisfied. Then you do sprint 2 and work on Y. You show Y to the client and the client sees it's not what they truly wanted. They gain insight into the product. So with that new insight, they might now think about it some more and realize that they don't need Z either. And now, your planned Sprint 6 that needed to start on October the 10th by working on Z is useless because you won't do it anymore. You need to redo your long term planning and see what you could do in Sprint 6 instead of Z, because the client just changed their mind.

Do these re-plannings often enough and in time you realize that long term planning is a waste when working on something that you don't really know how it should look like.

As Daniel pointed out in his comment above, when you know exactly what you need and how to build it, you plan it predictive style and you can decide on a schedule (but even like this, there might be some variance). If you work on something that isn't clear or has a lot of unknowns and assumptions, you can instead build it step by step and decide after each step what to do next; so at this point it doesn't make any sense to plan a lot of sprints in advance because at each step your plans and schedule can change.

Answer 2

There are more than two ways to estimate! What you are calling a "sprint schedule" is no help. It isn't a plan, it's really just a calendar of events.

It looks like you intend to use the Scrum framework and in Scrum you define a prioritised product backlog of items, with each item being a feature/outcome to be delivered (not a "task"). You can then estimate based on those backlog items, typically, though not necessarily, by using relative estimation techniques. Once prioritised and estimated you can slot the backlog items into a sprint plan based on an estimated sprint capacity, AKA velocity.

Answer 3

"How can someone predict the full duration of the project and the tasks that will finish in each sprint if the sprints do not contain specific tasks?"

You're asking how to apply a predictive approach to a scrum problem, but:

"A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility[11]) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited.

As such, Scrum adopts an evidence-based empirical approach – accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions." Wikipedia