Software development has had a checkered history of projects running over budget, missing functionality and delivering late.
A significant contributor to these failures is use of the waterfall approach to software development, where a specification is handed over to the development team at the beginning, and the first release of software delivered late in the development cycle, with user acceptance testing to follow.
Agile development methodologies came about to fix the problems inherent with this approach by increasing customer engagement throughout the process and continuous delivery of working software.
This avoids the awkward conversations at the end of a long project of “that’s not quite what I meant”, or “actually, could we do it like this instead”.
Writing good requirements is an art in itself, and unless you’re experienced in software development projects and have a strong understanding of your problem domain, then its unlikely you’ll get it right the first time, so its best to plan for ongoing changes in requirements upfront.
Today scrum is the leading agile development methodology, used by start-ups and Fortune 500 companies around the world.
The Scrum framework in 30 seconds
- A product owner (you) creates a prioritized wish list called a product backlog.
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
- The team has a certain amount of time — a sprint (usually one to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
- Along the way, the ScrumMaster (our project manager) keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
This process allows the customer (product owner) to continuously adjust the requirements if required, as its rare the initial requirements are exactly whats desired in the final product. The earlier in the develop that requirements can be updated, then the less the modifications will cost.
Also it allows the customer to always prioritise the the most important tasks and reduce the priority or even remove less important tasks, and manage the inevitable scope creep. This reduces the time to deliver the main functionality and reduces the cost/time spent on less important features.