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.
The who, what, when, where and why of user stories for Scrum.
An introduction to Scrum, one of the flavours of Agile, covering the team structure, processes and terminology in a brief handy overview.
Agile is an umbrella term for several software development methodologies that share a common philosophy defined in the Agile Manifesto, but have their own ideas on its implementation. This post takes a brief look at a few of those flavours.
The world of software development has changed. The world of web development is catching up. Agile is the future, waterfall is past – but persuading clients can be tricky.
This post is all about how to persuade a client that Agile is not only right for them, its the only sensible choice, with a few facts and sample answers to their inevitable questions.
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?”
