Customer: “When will you deliver the scope in our statement of work?”
Consultant: “We are Agile, so we can’t tell you that!”
Customer: “At least give me a high-level timeline. When can I expect to see my deliverables?”
Consultant: “Ask me again at the end of Sprint 3 after we’ve had a chance to measure our velocity.”
How many times has a conversation like this happened? Every day! This fictionalized exchange highlights a common problem in an agile environment: How do we schedule timelines for a complex project environment?
There are many ways to resolve this problem, but I will choose one to discuss in this post.
One approach
Begin with your backlog of epics, features or stories and work with your customer to prioritize them into “Must Haves” (needs) and “Nice to Haves” (wants). At this point, any further breakdown is probably not necessary, but you certainly can sub-prioritize your “Must Haves.”
Two assumptions factor into this approach: One, you have (or can easily) sized your short-term features/stories (those you expect to be in the first several sprints) already. Two, you have a team operating in an integrated development, testing, and deployment environment.
Consult with your customer stakeholders (or product owner) and project team members to align these features/stories against your sprints; at this point you know your sprint duration. Review features/stories to determine resource needs and dependencies, adjusting the feature layout as needed. Ideally, you know your team’s typical sprint velocity. If you do not, resist the urge to panic: after the first two or three sprints, you will have determined your team’s typical velocity and be able to adjust your sprint release plan accordingly. Keep in mind; you may need to adjust resources and/or scope to make this happen.
The advantages of a release plan:
- Your customers (product owners) have some visibility and input into when their stories/features will be available, enabling them to make their own plans, schedule product announcements and so on.
- It gives your team predictability to guide their planning and development activities.
- It forces sizing and prioritization of your near-term features/stories.
Things to Avoid
Spanning stories/features across more than one sprint. – Ongoing activities like integration testing, debugging, deployment, or performance improvements should be represented as finite deliverables bound by a sprint.
Constant reprioritization – resist inserting recently added or modified stories into near-term sprints. This can result in the shifting of previously planned features to later sprints and result in a failure to deliver a key, required feature. Instead, weigh the relative value of new requests against those in the existing plan before making changes.
Identifying all features in a sprint as “Must Have” — this makes it difficult to update in case of unforeseen risks, and results in so many updates to the plan that it quickly becomes ungovernable and unusable.
I’d like to hear from our readers on this topic, so please comment!