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.
Heard a lot about this Agile melarkey? Wondered what it involves? This post explains the processes and practices in running a project using an Agile approach.
It covers the concepts of the approach, explains the processes involved. Describes the meetings (or ceremonies) you should have, what to discuss and what their outcomes should be. It also explains who should do what, and when.
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.
Answers to questions such as “What is a functional spec?”, “Why is it important?”, “How do you write a functional spec?”, “What does it contain?”, “What does it not contain?”
The process involved in planning a successful website from the questions to ask your client to what to do with the information gathered, such as Information Architecture, Content Plans, Navigation and Layout.