Release planning with YOXEL SW: Collaborative planning session

May 22, 2007

If you have not read my 1st post Release planning with YOXEL SW: Starting a new release, please take at least a cursory look, because I will be using quite a bit of terminology defined there.

I strongly believe that forming a release plan should be a collaborative process. Even though the owner of the process could still be one person (release owner, product manager or Scrum Master) he should collaborate with a few more stakeholders who I will be calling release members. The reasons for such a collaboration are many and the main one is that one person even with good experience can overlook things and make mistakes easily which will result in irrelevant product release and losses to your business. Just think of what a product manager has to decide on before he/she finalizes your next release/iteration plan:

  • What are the important requests for the next release?
  • What are the interests of our customers? Are they all represented?
  • What are the different opinions on priorities? What are the right priorities?
  • What are the risks? How do we mitigate them?
  • What are the development and testing estimates?
  • What is the team/resource situation? Will we meet our deadline?

So, having more people controlling and participating in the process is better, it mitigates the risks. The key release members should be able to add requests to the plan, sometimes remove requests from the plan, specify their priority votes, specify work estimates, modify resource allocation, and be able to agree on all of those parameters … The release owner who has the final word should benefit from all that activity and in the end derive a more confident and backed-up final decision on plan content and priorities.

All important plan modifications, collaborative interactions, comments had better be captured in some kind of a release history log. So that anyone could always go back and see why a particular request was downgraded, or why a feature was excluded from the plan, and why the deadline was decided to be shifted. All that is especially important for distributed teams which do not always have an opportunity to communicate live all together. YOXEL SW release planning system actually provides all these capabilities. Once your release owner started a planning session, assigned the release members, and published a preliminary release plan the collaboration may begin.

Here is a typical sequence of actions for a release member that participates in a planning session using YOXEL SW:

  1. Read the description of the release goals. The very first record in the release history log will show you the release goal/objective.
  2. With that objective in mind review the current plan and add any important requests that are missing, in your opinion. You can add a new request if there is none yet in the backlog.
  3. Vote. Express your own opinion regarding request priorities in the context of the current release goals. The priority votes are used to do preliminary sorting of the items in the plan. They help all release members to see other member’s opinion and understand better what drives them. It makes alot of sense to have customer representing support people among your release members.
  4. The release owner has special order setting privileges, he can set exact order of the requests in the plan (1,2,3,4,…). He can always sort the requests according to the combined members vote too. It is his responsibility to know which items in the plan are the ‘must have’ requests for the release and which ones he could possibly remove later.
  5. The priorities entered by release members start to shape up the best order for the requests in your plan. At this point start inputting effort estimates. Usually your R&D and QA teams will have to get involved in the process and enter their estimates for each of the requests (perfect work hours).
  6. It is always a good idea to have representatives from your R&D, QA, support teams, marketing (CTO, Director of R&D/QA, Managers) as your release members in addition to just product managers. Let the R&D and QA release members be the judges of the resource allocation. By default, Yoxel tries to balance the resource load automatically but more often it is the case that the managers know the best who will/should be doing what. Agile teams that do not like the idea of resource allocation at this stage, can use the automatic balancing and ignore the actual names listed, it is still good for estimating your team velocity when you are doing your first iterations.
  7. Use ‘time sharing’ parameters if you are in the situation when the same resources are working on several projects for different products or if you have learnt from your previous iterations that certain % of their time they always spend on other, unrelated to the project tasks. Again, the teams following strict agile methodologies may chose to skip this if they already know their team velocity. In my opinion this is a convenient feature helping you to convert your perfect time estimates into realistic ones and preventing from underestimating.
  8. As your plan fills with the estimates start paying more attention to the details of the plan and Gantt charts. (Again, all depends on how strictly you follow a certain agile methodology, but I find it useful to check Gantts at least to see my potential resource bottlenecks). Look for the requests that are crossed (Yoxel computed time and thinks these are not making it into the release). Is that an important, a ‘must have’ request, or may be it is ok to remove it from the current plan? See if its estimate is reasonable (or entered at all). See if you can balance the resource allocation better. May be the release deadline should be adjusted? You can always collaborate with other release members by posting your comments in the release history log.
  9. Pay attention to warning messages in red and green that Yoxel generates. Try to resolve those, use reminders to grab attention of other people involved in planning. Allow some time to converge on a final plan with reasonable resource allocation and time table. Once all release members are in agreement, the release owner can save the plan and start the release implementation phase!

To support a wide variety of methodologies we tried to make YOXEL SW pretty flexible and forgiving. It is not enforcing a certain methodology on you; it support the one you choose. For example the simplest thing that it requires for transitioning to the next, release implementation phase, is for at lease the release owner to specify all his priorities and enter some estimates. Release members do not have to check GANTTS charts or do detailed resource allocation, developers and testers do not have to enter complete estimates for all the requests, release members do not have to priority vote on all the requests. You can spend very little time in the planning phase if you are in a hurry to start the execution of your plan and the list of requests is all you want. On the other hand if you want to be a little more conservative and prefer to think through the plan thoroughly, we provide all the necessary hooks, including breaking down requests into sub-requests, specifying dependencies, and accounting for two-phase blocking implementation (testing starts only after all requests have been implemented).

In my next post I will write about release tracking in YOXEL SW: how you monitor the progress of your iteration, how you detect where the problems are, and what you do to stay on track …

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: