If you can change what the team does, how is it possible to schedule for agile projects ? Saving Changes...
Sort By:
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
The backlog is prioritized to deliver 'value' incrementally. These prioritization efforts are continuous. Each sprint will have a goal in which the items brought in, support. There can be a product roadmap and release plan the product owner will support through those prioritization efforts, though, through regular inspection and adaptation, the release plan could change to accommodate other changes or feedback.
So while there is no 'schedule' as we know it, there is a sense of direction with a regular series of outcomes in support of an encompassing vision. Saving Changes...
Scheduling still occurs but at a higher level - perhaps one activity per sprint. Also, unless 100% of the scope of a project is delivered in that manner, some work packages might still be done in a traditional manner and need to be scheduled accordingly.
Hi Shadav, there is always a schedule, albeit at high-level during feasibility, your user stories constitute a small number of clear statements at this time, which are further broken down and assembled into PRL during each lifecycle, during the evolutionary development phase MoSCoW prioritisation is primarily used to prioritise requirements for each of your timeboxes, and daily stand up meetings ensure up to date project progress Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Every agile project* I've been on still has a schedule, but it's flexible. The "Roadmap," as we like to call is, forecasts what we expect to happen, but it gets more vague as we forecast further into the future. Think of it like a hurricane forecast: the storm experts can tell you where a hurricane will be tomorrow with a high degree of certainty, but the potential track gets very wide a week later. It's the same way with our roadmap; I can tell you with some degree of certainty what we'll be working on 2 weeks from now, but I can only guess where we'll be next year. (This is often true of predictive projects, as well, we just don't like to admit it.)
So an agile roadmap may not be 100% accurate, but the benefit is that it can be quickly adjusted based on empirical data to produce better forecasts. Those predictions can be used to negotiate using the same Iron Triangle that PMs should all be familiar with. By charting the amount of work done over a given amount of time (average velocity), you can predict how much would should be done in the future, and then you can visualize the scope, budget, and schedule. Do a web search for "burn up chart" and you'll find many good examples.
*The more mature agile teams I've worked with are more focused on "product management" than "project management." That may not seem like a big distinction, but a project has a defined end, whereas a product must be supported throughout its life cycle, which may not be well-defined. The point here is that what we call a "project" may not have a real project schedule, as we understand them. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
You do Rolling Wave Planning. You plan in details for the immediate and present then on high level for the vague future. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
We managed our current project using milestones, rather than schedule. This makes more sense because of the agile approach, yet provides senior managerment with anticipated deliveries of major functionality. Saving Changes...
Community Champion
