This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Estimating Frustrations on Agile Project + FIT
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
Not all things are always rosy in an Agile project just because it's Agile-). We like to think that our planning is more realistic with the Planning Game and Release Planning and that we sign up pretty perfectly for only the stories we think we can do in the iteration and it will all be 40 hour weeks and peace and happiness and love-). The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. The literature on Agile, and a lot of .NET “Agile“ blogs are filled with all sorts of information on this in theory from people not actually having to do this stuff all day long. And there are certainly frustrating parts of all this.
We first solved the problem on our team of taking 2-3 days to estimate our stories initially in and got it down into a few hours for our Iteration Meeting.. At that time, we had to get over our want to give perfect estimates and give course estimates to move the process along. But we found that in the last iteration, we didn't come close to finishing our stories for that iteration and in this one, we are 2 weeks + 1 day into a 3 week iteration without finishing a single story out of the 8-10 we have. There are a lot of good reasons. The domain is extremely complicated with lots of rules, and we developers don't understand it as well as we could. We also are very good at underestimating rather than the other way around-). But there's more. A frustrating aspect is that business is having a real hard time understanding the MMF that was picked themselves. There is a lot they didn't know either. That's where FIT added a lot of value to our process. James Shore talks about a vision for FIT. FIT isn't really, in his view (and mine), just a good tool for business to build Acceptance/Customer tests in their tools like Word. It's a tool for facilitating discussions about the domain at the requirements and design levels. In this iteration, it was the FIT tests that sort of forced business and development into long, fruitful discussions that fleshed out what it is we are really wanting as well as designing. And it was so much more than anyone thought. There were tremendous amounts of details in there that no one knew about until we tried to write the FIT tests.
We're all frustrated that we aren't moving “faster” (especially me) and a variety of other things but at least we have real time feedback that we don't know enough now, not 3 months from now. And maybe this is all part of the “process.” We will both get better at this - maybe it will take 3 iterations - for business to specify stories in sufficient detail and development to better estimate with our velocity.
Previous Topic
