Today, we just had an interesting realization about managing risks in projects. Particularly in how user stories gets prioritized and implemented.
I am currently on a short project that is expected to be completed in 3 weeks. In these 3 weeks we are asked to complete 3 user stories. Two of them involves changing the security model of the system and the third one is to Mavenize the application. The 2 security model user stories delivers user visible functionalities whereas the Mavenization story doesn’t. However, we believed Mavenizing the application will increase our productivity in delivering future stories.
None of us has had any prior experience in working with the application nor with Maven. Needless to say we are learning as fast and as much as we can as we are working through these stories – a typical day around here.
Now its story estimation time… since we are not familiar with the code, one thing we can do is we can look at one another and shrug our shoulders and say something like “that one over there is about a one and that one over here is about a one as well and …” without a whole lot of confidence. Or we can spike them. But wait, we don’t have time to spike them. So, instead we chose to start one security story and in a day or two it will gives us an opportunity to get familiar with the code and the development environment and then we can give a more reasonable estimate on the other security model story and only to shrug over the Mavenization story. At least our customer will have some sense of how fast can we deliver and prioritize a bit.
After a day or two (Week 0.5) of working on the security story, we had a chance to explore the landscape and we were quite confident with estimating it. We thought it will take the rest of the week to finish that story and another week for the other security story. We now only have to shrug over the Mavenization story.
We completed the first security story on time. At this point (Week 1.0) we need to decide whether to do the Mavenization story first or the other security story. We took the same approach as we did at the beginning of the project. We started to dive into Mavenization story for a day or two to explore the Maven landscape. Now its Week 1.5, we say that should take about the rest of the week to complete this story. Perfect, with one week left, we will be done the last story right on time!
However, this time we didn’t get as lucky. Mavenization turned out to be a lot harder then we thought and we are bleeding over our original estimate of one week. At the end of Week 2.0, we are still half-way through (maybe ?) mavenizing the app. But worse, because mavenization is not finished, we found ourselves in a position where our build is now busted. This means we can’t even spawn another stream to start working on the other security story without finishing Mavenization. Mavenization is now on our critical path. This is not a good position to be in, where each additional hour we spend on Mavenization is equal to an hour lost in working on the final story. Stress is on.
In retrospect, we realized we did not manage/identify our risks very well. The risk in Mavenizing the application is far greater than we naively thought. When you think of it, Mavenization is like a performing a “triple by-pass” on your build system. You now have to explicitly manage with lproject and ibrary dependencies and their versions. As well, the recovery of such surgery could mean your development tools may no longer work as smoothly as before. Specifically, if you use maven to build and deploy your application into JBoss outside of eclipse, hot code replacement in eclipse does not work anymore. Keeping your code in-sync with the container is no longer managed by MyEclipse. Redeploying the entire app each time when you make minor modification a JSP page could drive you insane pretty quickly. We are now seeking tighter Maven – Eclipse integration.
One thing we should think about when managing risks in user stories is to ensure the stories are implemented in such a way that you are not to paint yourself in a corner where the moves you can make is limited. Thats when the risk of the project is at the highest.