Our roadmap

taw first roadmapHere we are… our road map is done. We have increased our guessed velocity and we have changed the order of some user stories. From the photo you can see the famous post-it used in Scrum mode. The photo  is taken with Sebastien device, not a powerful one ;).

Thanks to Celine to have changed our ugly header blog with her beautiful drawing.

First week is passed. On monday the first sprint will start even if not all the team members will be there. That’s all for the moment… “bon weekend”!

Roadmap is done

Well, at least of first version of it. We barely managed to put all the stories to make the new feature at the same functionality as the old one, so no wonder Claire looks disappointed 🙂

However, the team feels confident that we are capable to do more than that. Guess we’ll have to see after the first sprint for how it goes. The main worry is all the testing activities, but I am more optimistic (unrealistic?) about this.

Velocity estimation was done in two steps. First we took one story (a 1-point one) and split it into tasks, estimated each of these tasks, to arrive at a stunning total of 8 days (which would mean a velocity of 5). When looking at the story globally, everyone agreed that 4 days should be a max. So we reverted back to a “best guess” at velocity (10-13), which still looks a bit pessimistic to the team. Wait and see 🙂

Planning the release

Today we created a rough product development roadmap. Normally there are two questions used to initiate the release planning:
– When do we want the release?
– What is the priority of each story?
For the first question not much choice, the date is fixed by the next release of the product at the beginning of September. Generally this bring to have a release planning with fewer variables to consider but with more difficult decisions about wich stories to include…  this seemed really the case. To decide the priority of the each story we used as a first step the MoSCoW rules (Must have, Should have, Could have, Won’t have this time). Claire assigned the rules, then the priority to each user story considering the desirability of the story.

From story points to expected duration
With each story estimated in story points what we needed was to convert these points into predicted duration for the project: the answer is to use velocity, the amount of work that the team can done in an iteration. To get the initial team velocity we took a guess (no historical value for the team, wait to run an initial iteration?). Our estimated velocity was at the end 12 so not possible to complete all the user stories for the fixed date, but this doesn’t mean will be our real velocity, after every iteration another more precise estimate will be done, changing the release plan.

Creating the Release Plan

The final step was to allocate stories into each iterations (6) following the priorities given. The result has been to have many user stories left outside of the plan, among them many user stories that marketing consider also as “must to have” for the customer… Claire didn’t seem very happy looking at the release plan. In any case tomorrow, planning the sprint iteration, we’ll take a look another time to our velocity and if we’ll see some important difference we’ll change it.