Previously I blogged about what user stories in scrum should look like, providing an overview of their format and principles, but not really covering a how you come up with them all or how you decide what order to do them in.
This post covers who needs to be involved and recommends a practical 10 step approach for creating the Product Backlog.
So Agile is all about working software over comprehensive documentation right? But if I don’t know the detailed requirements up front, how can I estimate for a task? And if I can’t estimate for a task, how can we figure out how long the project will take and how much it will cost?
This post covers techniques for quickly and easily creating reasonably accurate, high-level estimates in the project kickoff meeting that are sufficient for resource planning and scheduling.
When estimating for a project that you’re not sure you’re going to be awarded, you don’t want to spend too much time analysing the minutiae in the spec. So what do you do when you’ve won it, you’re half way through building it, and you stumble across a small, but fundamental problem?
Software developers will always be asked to estimate for work, so that project costs, timescales and resource requirements can be planned. Much as you’d like to just get on and build a web application, this, unfortunately, is a fact of life.
If your estimates are wildly under actual times, there can be repercussions. If you work for yourself you’ll most likely take a hit on the profit you’ll make on a project. If you work for someone else, your boss might not be too happy as the company has taken that hit.
This post talks about how to estimate, types of estimate (with a section on ballparks) and how you can manage the use and interpretation of estimates you provide.
