It's fine to estimate in Story Points, but I need to be able to say by when you will be finished, or whether I will be able to complete the tasks by a certain date. How do you do this?
The bit explaining velocity and sprints is really just a sentence... It may deserve a bit more emphasis. It makes sense to me, but to someone who isn't familiar with it, it is easy to gloss over that part.
And you also don't mention that if a manager wants to know when something is done more frequently than once a week, there's probably something else wrong there. Nobody should really be managing developers hour by hour, you're just going to kill productivity. Are you building a product in the long term, or are you micromanaging every paragraph of text on the web site, etc.
I'd love any feedback from anyone who has managed to make changes in how they estimate at work as a developer; too often the whole estimation process is decreed from the top downwards, and developers get too little say in improving project-level working practices.
Planning poker has worked for me at companies that didn't otherwise adopt any agile processes. It's better if you use points in a more comprehensive way as mentioned in the article but a lot of umm... "people" just don't seem to get that abstract nature of it. Well, that may not be fair, but they definitely don't care. I have found it works just as well if you just call points "hours" because the most important part is having a bunch of people in a room talking about how difficult a task is going to be relative to the other tasks in a project. Estimation is one of the hard things to do, and if you can demonstrate a process that helps with that, people are more likely to try some of those other "crazy" ideas you keep ranting about...
