Experiences in Release Planning: Two Days in the Life of an Agile Newbie

[article]
  1. might ship sooner, it might ship later based on outcomes, but in any case, that was the target. And, no matter when it was actually released to the market, the pattern of iterations and internal releases would not change!

Easy for her to say , I thought to myself, but how in the world are we possibly going to do that? I wondered.

She then stated the objective for this meeting:

"Today and tomorrow, we'll lay out a rough plan for the first internal release, work through interdependencies and issues, and come to a point where we can make a commitment to our company of approximately what we will have ready for evaluation by users in 60 days. Not a perfect commitment, but a prioritized one, and one where we have a high probability of accomplishing at least the highest priority features we agree to."

She then continued:

"If we cannot reach the point by today by 6 p.m. today, then we'll meet again tomorrow and cut the scope if necessary until we have a plan we can commit to. If that fails, we'll stay here until we get a plan that works.

Whoa, she may be bluffing, but she definitely has my attention now!

12:00 - 3:00 Team Breakout Release Planning

The next three hours were a whirlwind of activity. Pizza was brought in for lunch but I don't remember anyone relaxing and enjoying eating it. Since I was new, the product owner on my team, Lawrence, who had been a developer here for some time, led the next part of the discussion. He had met with product managers ahead of time and had a decent understanding of the features that had been described earlier. For an hour or so, we brainstormed all the "stories" ( things we would need to do, with a focus on "value delivery" which means, I guess, things that users, rather than developers, actually care about ) that we thought we would need to do in the first three iterations to accomplish the release objectives. As we thought of them, we wrote them down and put them on a wall on a 4x6 sticky note. Intermittently, a product owner, team lead, or system architect from another team would come to the meeting and ask about dependencies we might have on other teams, or highlight some of the major architectural development we needed to have underway as well. Sometimes this caused more stories to go on our wall; sometimes we got rid of stories when we discovered that another team would handle them.

After about two hours, we had identified all the stories we thought we needed and we went through a process of "building" the release plan. In this process, we first estimated each story in "story points" (a process I won't bother to describe here but suffice it to say that we generated a very rough idea as to how big each story was). Then, we placed the stories in one of the iterations in the release plan until we ran out of capacity on the team to do more stories. (We were told not to place any stories on the last iteration for some reason, but we felt we had to because otherwise they didn't all fit). We talked about sequencing and dependencies of the stuff our team would develop, moved things around a bit, and then put in a few stories for integrating code that we could expect from others. At the end of this time, we had visual picture of what we needed to do by when (see Figure 2).

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!