"Sprint" and "Scrum" without breaking a sweat!
Working by the Agile Manifesto allows a company to ensure project costs are kept down to a minimum.
Is it too late to…?
One of the main disadvantages of working by a traditional Waterfall approach is that any changes to the spec will add significant time and cost to a project. With Agile, amendments and spec changes can be incorporated into the work as the project progresses due to the high levels of communication between the development team and the Product Owner and Project Sponsor.
If you think about it, creating the vast majority of documentation at the start of a project and making big decisions regarding direction does not make a terrible amount of sense. This is the stage of a project when the least amount information is known by the supplier and the client. Agile allows both parties to provide input after work has initially started and is progressed. This means that decisions are made on the back of having much greater understanding for how the project is materialising.
Waterfall methodologies often carry with them rigorous change control procedures. This means that if a person from the client or the supplier side has a great idea that will significantly enhance the project, the time it takes for this idea to be documented, budgeted and then accepted by the client, workflow is slowed down and disrupted. Sprints (detailed below) ensure that this does not happen as the increase in project elasticity means that the client is not restricted by regimented documentation.
Epics & Sprints
The work that needs to be completed is placed into "epics". These are essentially category titles for all of the work that needs to be undertaken. The epics are then filled with tasks that are converted into “user stories” that each have their own “acceptance criteria”. A good user story follows the INVEST mnemonic. Wikipedia defines INVEST as follows:
Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable: User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable: A user story must deliver value to the end user.
Estimable: You must always be able to estimate the size of a user story.
Sized: User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable: The user story or its related description must provide the necessary information to make test development possible.