What is an Agile project?
People often enquire as to whether and lack of detailed planning increases the risk of scope creep. Any piece of work (or product) that’s introduced into the project should be related directly to an expected project outcome. This is true for both work initially counted as in the scope of the project, and also for any change introduced during the project lifetime.
Agile projects often use something called User Stories for requirements: these include a stated business value to be achieved as a result of implementing this requirement.
User Stories in Agile
User Stories are normally written from the perspective of the end user of the product, and so are easily understandable by all stakeholders. This leads to high visibility to all stakeholders as to the work being done, and to the work that’s been prioritised to be completed next.
There are regular and frequent opportunities to review the work that the project team has done and is being asked to do next, and to course-correct if necessary. This review isn’t done by just the project manager and project team, but by all of the project stakeholders.
If we are ask to introduce work into the project that doesn’t relate to a project outcome, this would flag up that the document that defines the project, the project charter or business case, needs to be reviewed with the project stakeholders.
User Stories have a standard format: As a user, I want to do something, so I can achieve some business value. For example: As a registered bank customer, I want to filter my bank account transactions by a date range so I can see what income and expenses I had in that period.
Completing this piece of functionality will normally require people with different skills to work together. This increases collaboration, as the team are actively exploring ways to reduce the work for the whole team, not just for themselves.
Estimating for Agile projects
Estimating on Agile projects is done collaboratively, and includes the customer as well as the development team. The practice of relative estimating, making use of a tool called Planning Poker, is very popular with Agile teams.
Since each User Story is estimated in this way, it is a highly effective way to ensure that there is a shared understanding of the customer requirement. There is a guide on Story Card estimating (Planning Poker) on Solnet Solutions > Tools.
As the customer builds up trust and confidence in the team’s ability to deliver against these estimates, these highly collaborative estimating sessions become a very effective planning tool. Priorities and trade-offs can be very readily understood; for example, a User Story of low business value and high relative effort to deliver may quickly be discarded. Agile is about minimising the amount of work done to achieve the required result.
My objective was to respond to some of the comments I’ve heard about Agile, and to answer questions I’ve been asked related to planning and estimating. I hope that I’ve piqued your interest, and that you are keen to peep further under these covers.
