The agile project management technique of planning poker is a popular estimation process for software development. My favorite Agile author Mike Cohn presents a good description of the practice on his blog here: http://blog.mountaingoatsoftware.com/?p=14.
Let me start off by saying that I really like planning poker. It’s a very clever way to estimate user stories. However, from a tech startup standpoint, where time is a critical resource, planning poker becomes a non-essential part of the agile process. Here’s why:
- The cost is material. My typical 2 to 3 week iteration has approximately 40 stories. I find that it takes between 2 to 5 minutes per story. Using 3 minutes as average, that brings us to 120 minutes. So my team of 10 people, spend 2 hours in planning poker. Multiply that by $75/hour and you get a cost of $1,500, not to mention the opportunity cost of not coding. At a startup, where time is so valuable, this is a tough pill to swallow.
- After several iterations and planning poker sessions, I began to realize that I could estimate just as good as the developers. I would compare actual hours reported by my developers spent on user stories to the story points estimated and calculated that my estimates had the same standard deviation as the whole team did the estimation. Even if you continue to practice planning poker, this is an excellent exercise to refine your estimating skills.
- Take shortcuts. The average bug tracked in our bug tracking software is about a 1 story point. Skip estimating every bug and just apply this average.
- If deadlines are less critical to your particular situation, then why care so much about your estimates? My web application dev team often has a release plan that changes every couple weeks. We are not tracking a burn down to know when the release is complete, because the story make-up of the release changes so frequently. The burn down chart is not actionable for us.
On particularly large stories or Epic’s, I ask the developer who will probably be working on the story to give me their estimate. But for the majority of user stories, I take care of the estimation. Maybe you can too?
This is one of the first books that I have read on the topic of Web Analytics. This book is not a deep dive of a particular tool like Google Analytics or Omniture, but rather a comprehensive description of a web analytics framework (Trinity) and a 6 month plan to implement. The book is targeted more towards medium to large companies. A small startup like my own couldn’t begin to implement all of the suggested actions. In some chapters, Avinash clearly notes which strategies (such as the testing chapter) are best for companies with limited resources, but overall he doesn’t always do this. I would have like to see him make minimum suggestions or short cuts for companies that don’t have even 1 FTE dedicated to web analytics.
A few key points from the book that I really found beneficial:
- Heuristic Evaluations: An easy way to quickly determine if a web page is designed well by going over a checklist of about 20 basic design rules of thumb
- 10/90 Rule: Spend 10% of your web analytics budget on tools and 90% on people.
- Web Analytics function should align with the business, not IT.
- 10% variability in web tools is not uncommon.
- 2% is standard conversion rate
- In Google, type in “site: <www.yourdomain.com>”. This will show you how well Google has indexed your site. If Google shows 50 pages, and you know you have 200, then something is stopping its spider from indexing your entire site.
- http://snipurl.com/poplink. Great tool to quickly view your website ranking across multiple search engines for a search phrase.
- 80% of the time, company employees are wrong about what customer’s want.
- About 20 search phrases represent the majority of search engine traffic to your website.
I definitely recommend this book, but be ready to pick apart what you can realistically do in the amount of time you can afford to spend on web analytics.