Friday, October 24, 2008
The first release plan, pragmatic
Eravamo io, Paco Gongora, Fidel Castro, l’Uomo Ragno, Maurizio Micheli, Diego Armando Maradona… no, just kidding (I remember the great imitation of Gianni Minà by Fiorello!).
We were just me and the product manager. We haven't a team of developers yet!
I introduced some concepts to my product manager about the planning technique. I started to tell him that in the agile jargon he is not the product manager anymore, but the...product owner! Pronunced "il produttone". I quickly explained him things such as what is the customer proxy, what is a user story, release/iteration planning, buffering stories for uncertainity... basically the outer loop. He seemed to understand and approve! :)
We inserted all the bugs, enhancements and ideas in Bugzilla for weeks, now it's time to plan the next release and protect the team (only me, sigh!) from continuous interruptions for feature requests (grrr).
So, let's write stories to implement ("che storia!"). Ok, these are not real customer stories in the orthodox meaning, but just issues that we have to plan.
Story preparation
- Enumerate all NEW issues in Bugzilla, we had about 60 issues.
- For each issue, discuss meaning and scope of each one, if there are doubts. Write a stor on a card with only the title and Bugzilla's issue id on the top right corner, and highlight it in red if this is critical (write in the body only some clarification if necessary. We are developers plus the product owner, it's just redundant to write the story in the usual lengthy format, I think that that is useful only for the customer).
- Set ASSIGNED for the issue in Bugzilla, so we remember that the issue has already been processed.
- Let the product owner prioritize stories. This must be done before the complexity estimation, so the developer knows whether it is important to split a story or wait the next iteration. The prioritization is just done in the way "this comes before than that". Then we numbered the prioritized list to save us from the risk that the cards get out of order. If possible, write the business value (for example using a Fibonacci scale: 100, 200, 300, 500, 800, 1300...), it describes better the order of magnitude of importance.
- Estimate complexity using relative comparisons. I like story points, but I think they work better in a team environment. For myself I tend to think in ideal days, so I'm using this unit of measure at the moment (using always the good ol' Fibonacci scale). For one developer alone I think that story points and ideal days coincide though. In fact I tried both! To test the story points I tried the following procedure: since we have so many stories and no experience with story points I did a two-pass refactorying of the stories. In the first pass I quickly divided them in S, M, L, XL size. In the second pass I converted the size to a number using the Fibonacci scale, starting from the M size and assiging it a 5, from there it was easy to set S=1,2,3; L=8; XL = 13 or greater. The numerical difference with ideal days was neglectable.
- Split stories with high priority (business value). Go to step 1.
- Decide iteration length. Being the first time, we try with 2 weeks.
- The velocity is unknown yet. This is the total of story points completed in one iteration. I haven't historical values and we are not asked to make a forecast for a customer. Moreover, we decided that the release will be feature driven instead of date driven, so the best way should be to run some iteration and observe the velocity. Let's start by implementing the stories with highest priority first and see how many story points we can complete in 2 weeks.
- When the velocity is known after the first iteration (or better the average of the first 2 or 3 iterations), let the product owner decide which stories to implement so that total_story_points <= velocity*number_of_iterations and the total_business_value is maximized.
These steps are mostly inspired by Agile Estimating and Planning.
Thursday, October 2, 2008
Back from Intergeo in Bremen
My first month in the new company is gone. Lots of things to do: move to new the house, set up a minimal development enviroment and sniff around the situation. In fact I just came back from Intergeo in Bremen to see the state of the art in geomatics.
Lots of planning to do now in order to define development priorities. Find people to hire.
At the moment I have just installed Bugzilla and TWiki for the company intranet. I had to uncover from the dust my skills with Linux... there is my blood on the keyboard!!!
I have switched from Subversion to Mercurial. I have tried also Git, which seems in the trend now, but I found it not as smooth as Mercurial, at least on Windows. Maybe I will post something more detailed about it in the future.
Back to work now...
Subscribe to:
Posts (Atom)
