High level estimation for an Agile project
Hi,
In ongoing scrum projects, team size the user stories by story points and pick the ticket based on their velocity. I would like to gain some suggestions on approaches that cane be followed before starting a project. In initial stage, the sponsors/business would like to know the duration and estimation for the project. The stories will not be detailed and their will be very high level information on the requirements. Even the complete team itself may not be available to size the epics. In such situation how can we derive a ball park estimation and duration? Please share your suggestions.
My opinion is that projects cannot be agile. Projects are always waterfall. There is nothing wrong with that. The construction of a building is waterfall. Software should be agile. And when it comes to project work, everything at the initial stage is a wild guess. It's all based on perspective and experience. This is why projects always go over budget, out of scope and over the allocated timeline. That's the nature of projects.
the sponsors/business would like to know the duration and estimation for the project.
Exactly one Sprint. In Scrum, a Sprint may reasonably be seen as a project. One Sprint is how long stakeholders can expect to wait before seeing evidence of value. Informed decisions and forecasts can then be made.
In my opinion the SM in this situation should work with management to find out why they need a forecast/estimate of the project. If they support the team in following Scrum, then they should realise that forecasts, especially ones early in a project are often wrong the minute they leave your lips. The benefits of being agile and responding to change should far outweigh the need for a forecast.
If they insist on a forecast, review alternative frameworks with the development team to negotiate the pros and cons. The reason Scrum exists is because the old Gantt chart way of working was inaccurate from the minute you created the diagram.
Remember that any forecast you make is on the assumption that all of the requirements are known and well scoped. By your own admission, they aren’t, and is all requirements upfront is Waterfall (and we all know how that goes!).
Honestly I feel that sponsors and business have every right to ask "how much will it cost?" and "when will you finish?", since they are most likely funding the effort. Yet the challenge we face is that at the start of a project or effort, it really wouldn't be professional for us to commit to timelines, cost (budget) and scope with any certainty. We need to have courage to speak up and do the right thing. It is also important to work with those asking you about dates and budgets, and talk to them about the uncertainty that comes with the complex world you work in, how things will change, and how empiricism can help.
Probabilistic forecasting uses ranges and probability and is something you could look into - in other words the forecast is not a guarantee. If you have some Scrum experience and time on your hands to take a PSK course, it might help you with forecasting. Dan Vacanti's book "When will it be Done?" and the Scrum with Kanban blogs are another option if you cannot get to a course.
If you have historical data data and the right tools (Scatter Plots, Throughput Charts, CFDs), you can use that data to help with forecasts using Monte Carlo simulation. Here's a blog post to give some ideas on what I am talking about: https://www.scrum.org/resources/blog/create-faster-and-more-accurate-forecasts-using-probabilities