How To Give A Schedule
From AgileOpenNorthwest
Contents |
How to give a long term schedule
Co-hosted by Scott Porad and Bruce Winegarden
We had about 8 – 10 people join this session and I apologize for not getting everyone’s names down. Now that I’m writing up these notes, it would be good to attribute some of the comments. If any of you are reading these Wiki notes, feel free to add your names and comments.
Scott started the session by asking, “My boss / customer / partner wants a schedule for when “x” is going to ship. How can Agile give it to them?”
We discussed the challenge of making long term commitments and then meeting them. Scheduled delivery commitments we talked about were generally in the 3, 6, to 12 month timeframe. The consensus was that a “roadmap” with a schedule was a good way to communicate the schedule.
Two strong pieces of advice came from participant experience:
1. Work with your customers / stakeholders / boss to create a single rank ordered list of features to be scheduled. Their experience was that this works much better than asking for priority rankings, as too many things tent towards the “highest” priority to be meaningful for making decisions.
2. When making a commitment for “feature x” in the schedule, you need to clearly communicate what other items may now have slid down the schedule. It is important to engage your customer in making these trade-off decisions so they understand that if they new want “x” by June, they are not going to get the previously promised “y” and that “y” was displaced to July.
Managing Work
It seemed like a pretty common practice to also approach the work in a similar fashion to the rank ordered roadmap. Several people said their teams performed better when they focused on one major feature or epic story at a time. While this may get broken down into multiple smaller stories, it keeps the team focused on a single primary feature at a time. This does not preclude working on sustaining issues or customer reported bugs.
Several people described how they reserved a certain proportion of velocity committed to smaller sustaining stories such as addressing bug fixes and more immediate customer requests. These “sustaining” stories were done in parallel with larger new feature stories. At lease two different people said this proportion split was roughly 50/50 for their agile team.
Estimating a Schedule
We spent a fair amount of time talking about how to estimate these stories and came up with 3 similar approaches:
1. Categorize stories into different “sizes” and instead of estimating use empirical data on your historical performance for past stories from these categories. Do look at the variability (statistical deviation or bell curve) to validate that the chosen category groupings make sense. While this approach to use historical performance rather than estimates was illustrated by referring to a Kanban planning approach we also agreed it was applicable when using Scrum sprint or xp iteration cycles. During the session we referred to the Lean Kanban approach that Wayne Allen described in his earlier 9:30 Tuesday session on Lean. Participants also recommended looking on the Internet for prior sessions by Arlo Belshee on “Naked Planning”
2. Where empirical data is not available, use “T-Shirt” sizing to group stories by “small”, “medium”, and “large” consulting with people you trust to provide experience based subject judgment (aka best guess). There is a subtle difference here from the typical practice of having developers estimate stories during iteration planning and this does not necessarily replace that practice (unless you adopt the Kanban approach). The key difference is that you are estimating in a different way. By categorizing stories into a group and then estimating the average time for all stories in that group you are more likely to arrive at a schedule that is more accurate in the whole. Don’t try to do this with two many different sizes, 2 – 3 was the maximum recommended.
3. “Bucketing” was a similar suggested approach where you would put a group of stories into a bucket and then estimate the bucket.
Managing the Roadmap
We also discussed ways of managing the “roadmap” and how it relates to “backlog.” I think of the “roadmap” as the rank ordered backlog with schedule commitments added. The roadmap is a communication tool that should be reviewed at least quarterly. Imprev, has good success presenting alternative “roadmaps” as Gant Charts so customers and stakeholders better understand the schedule tradeoffs as they ask for different options.
We also discussed the idea that features and requests get filtered into either active backlog or are shelved and held for later consideration. One story tracking system uses “backlog” and “icebox” to describe this categorization.
