Drupalcon London - Drupal Estimation Techniques BoF

Here are the notes from the Drupal Estimation Techniques discussion I organized at Drupalcon London. Feel free to share :) I want to thank Drupalcon organizers for making this possible -- we really appreciate all the effort that went into the creation of this conference and its BoFs. Second, thanks to Jakob Persson (Co-founder & Web Strategist at NodeOne) for co-chairing and to everyone who came to share their ideas and experiences with the group. We all had a lot to say, hopefully some presentations for Denver will come out of this! We asked a series of questions at the beginning of the BoF hoping to spark conversation. The goal of this BoF was to understand the challenges the participants face, and how they addressed them (successfully and unsuccessfully). We decided to hold this BoF because the Drupalcon sessions didn't specifically address these issues this year, and Jakob and I are both very interested in maintaining conversation about them. I hope the responses/ideas/experiences we generated below will be useful to you! Best, Shannon Vettes Bluespark Labs Project Manager ps: notes were taken quickly & during discussion so, they risk being incomplete! Please feel free to comment below so we can add more info here!

Q: What makes Drupal estimation different from non-framework development?

Top responses were: => Research: we need to see what's out there already to know what we can exploit => Testing: we probably need to test out things to verify functionality & expectations => Dependencies: There may be 3rd party code we need to interface with or other modules we're dependent on => Security updates & maintenance: there is more involved in maintaining your code, especially with custom work or new Drupal versions Interesting point: Most of the group aren't including these things in estimations, proposals, etc. Most are putting numbers on quotes that represent the time it takes to *do* the work w/o including the prep work or maintenance. But is this the best approach? The things listed above are very valuable to a client, who is buying a product, but they're also buying your expertise!

Q: What kind of projects are people estimating right now?

Top responses were: => Fixed bid: this seemed to be the most common response. The client provides a list of requirements, the company works to create them for a specified budget. => Time/Materials: only 2 or 3 shops at our BoF were doing this kind of work with no fixed scope & budget. Other questions: I wonder if this is a European trend? It seems to me (just a gut feeling, not based on any real data), that a lot of shops in the US are moving away from fixed bids. Anyone care to weigh in?

Q: What should we consider when estimating? What "factors" affect the numbers?

Top responses were: => Developer(s) experience level(s) (Consider experience with Drupal itself, the version in question and with the feature being estimated) => The context (ie: which Drupal version? Are all necessary elements ported to that version yet? Is there custom work? Is there a migration or integration points?) => The client (Is this a client who is easy-going and manageable or someone who will constantly challenge scope & ask for more work? Note: if the latter, more PM time should be added for change management) => The constraints (do they need this done quickly? Is that going to jeopardize other projects -- maybe a rush fee should be applied if that is the case.)

Q: What techniques work well for Drupal development estimation?

Top responses: => building in 10% into the budget for research & architecture into your quotes => letting the client know how Drupal works and that there may be some dependencies (see list above) and level expectations from the start => planning poker / delphi method ---> there's an online tool listed below that's useful (see resources below) => spreadsheet to estimate that takes into account bottom-up estimation techniques with an average of high-med-low guesses to get a more accurate guess => padding estimations considering the developer's past experience (ie: developer says 3hrs, but I know he's slow, so I'll plan on 5) => always orienting the estimation toward the option that favors the business need to trim scope & the estimation time according to what is most valuable to the client! => collecting previous estimation data & benchmarking your results for usage on other projects

Q: What techniques don't work with regard to estimation & proposal preparation?

=> estimating without considering the research => project managers estimating w/o discussing w/ the team => fixed bid + agile - change control = scope creep! => saying yes all the time => not managing change on the project & adapting the cost accordingly

Q: Disaster stories you learned from (what blew up in your face)? What are the lessons learned?

=> Working with inexperienced Drupal developers -- LL: know who your developers are and their skill level before estimating & agreeing to a project => Accepting rescue missions without proper investigation: -- code/site audits are crucial to being able to evaluate the necessary effort -- not having a clear idea of scope when starting these missions will bring imminent failure -- level expectations about changes & issues that may crop up "this is not my code, ergo, it's unpredictable!" -- LL: really *know* your project. These kinds of projects are great candidates for waterfall methodology or for a retainer allowing you to do fixes over time and better manage budget, scope & expectations.

Q: Any tips/tricks/resources you want to share?

=> Presentation by Jakob Persson from Drupalcon Chicago, Getting Early Estimates Right => Blog "10 ways to Rock Your Project Planning" by Shannon on Bluesparklabs.com => ActiveCollab is a tool appreciated by some but not all at our BoF => Aegir is a technique appreciated by some but not all at our BoF => Book: Drive by David H. Pink was discussed and sounds interesting => Book: Rework by Jason Fried was mentioned => installing an admin theme that hides all the critical security updates for everyone but you to avoid clients getting big "security update" messages that create more worry than their worth. => using online tool http://www.pivotaltracker.com to promote estimation without influence between multiple developers => Effect mapping (maybe there will be a Denver Drupalcon session on this?) Note: Jakob and I both have estimation spreadsheets. Jakob's is available Here or you can contact me at Shannon@bluesparklabs.com if you'd like to see my own.