Request More Information

We are hiring!

Xtivia, Inc.
2013 North America Liferay Partner of the Year

Join our top-notch team of Enterprise Java and Liferay Portal professionals in our Austin, TX office or work remotely! Please check out our current Dice listings.

Recent Bloggers

Luke A Smith
Posts: 17
Stars: 0
Date: 10/20/14
Sonu Verghese
Posts: 7
Stars: 0
Date: 10/16/14
Chris Shaw
Posts: 8
Stars: 0
Date: 10/15/14
Sushil Shirodkar
Posts: 1
Stars: 0
Date: 8/28/14
Vamshidhar Srikantapuram
Posts: 11
Stars: 0
Date: 8/8/14
Barrie Shaw
Posts: 6
Stars: 0
Date: 8/4/14
Omar Yimaier
Posts: 4
Stars: 0
Date: 8/1/14
Bob Dietrich
Posts: 8
Stars: 0
Date: 8/1/14
Matt Wolinski
Posts: 2
Stars: 0
Date: 7/30/14
Richard Ngo
Posts: 1
Stars: 0
Date: 6/19/14
« Back

Release Planning in an Agile Environment

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!

Comments
Trackback URL:

Anonymous User
Just wanted to point out that the question of: "How do we schedule timelines for a complex project environment?", represents not a problem of an agile environment, but a problem inherent to software development.

Estimation always gives a false sense of security, no matter how exhaustive your methods of estimation are, you will almost for sure be wrong (unless very lucky).

There is a relation between how big your project is and how bad will be your estimations. I think focus should always be on delivering working software as soon as possible. "As soon as possible" includes not wasting time by trying to know for certain when the stuff will be available.

Let's suppose you have a good estimation technique. Starting the project you can come out with a list of "must haves", then you estimate them, and come out with a date. I say that's also a waste of time, because those "must haves", will very likely going to change, and there it goes your estimation.

I'm not advocating for not telling anything to customers. What I say is that you should try to estimate reasonably and fast, give them something to work with, and then do your best effort, not directly to be delivering in that exact date, but to work with such practices that the customer has all possible visibility to enable him to make decisions. Do also your best effort to deliver as soon as possible, starting from a imperfect complete solution and iterating according to your favorite agile practices from there.

I hope my thoughts are clear to you, as english is not my native language. emoticon
Posted on 2/15/13 11:03 AM.

Request More Information