In Part 1, we looked at what Agile methodology means to the stakeholder. We identified the challenges involved with software development and showed how Agile development addresses them by drastically reducing the time between identifying the valid business need and putting the solution in front of stakeholders. Here, in Part 2, we outline six steps that help ensure a project’s success.
Agile in Practice
As a client or stakeholder, you might ask yourself why any of this is relevant to you. “If this is the way development teams need to work,” you might say, “then great — they should do that!” But your role and participation as a stakeholder are vital to the success of this approach.
Step 1: Break it Down
One of the first steps for the development team is to break down the work into small chunks. Based on your project requirements and goals, the team generates a to-do list called the “product backlog.” Each item in the backlog represents a small piece of functionality, such as a user’s ability to perform an action like logging in. Working through each to-do, or backlog item, allows the team to implement features in an incremental, iterative way. For you as a stakeholder, this step can include participating in a discovery workshop, story mapping activities, and discussing project vision, goals, and strategy. The purpose of this early collaboration is to reach a shared understanding of what the development team will build and why. They will have questions for you about initial scope, specific features, content strategy, and more. Alignment between you and the team at this stage is what will start the project off on the right foot.
Step 2: Estimate Everything
Once the backlog is created (usually in a project management tool like Jira), the developers will estimate each backlog item. The estimates help the team (and you) to understand how much work each item will take to implement, relative to the other items in the backlog. Most Agile teams use a point system to do this.
As a stakeholder, you may have visibility into the estimates, which will help you give input on prioritization decisions throughout the project. It’s also important to remember that estimates are just that — estimates. They will be imprecise, but they will be updated and refined as the team progresses through the work and accumulates knowledge.
Step 3: Prioritize, Prioritize, Prioritize
The product backlog isn’t ready to be worked on until it has been prioritized. Prioritization will be based on multiple components, including business value, estimates of effort, and various risk factors. It’s important to note that the reason the backlog is one unified list is that the priorities will be ordered from top to bottom: each item in the backlog is a higher priority than the one directly below it. This means that no two items can be the exact same priority, purposefully forcing some tough decisions.
The development team’s project manager is responsible for maintaining the backlog, ensuring that it is clear and accurate. The PM will need your help to understand the details and value of the backlog items. He or she is likely to ask for your input on priorities and will ensure that the backlog is prioritized correctly to make the most use of development time.
Step 4: Start Building
Once the product backlog is prioritized, the developers can begin implementation. They will pull items from the top of the backlog only. This means the most important work is always done first, saving lower priority tasks for later.
When the team selects a backlog item to work on, it will go through multiple phases in quick succession, such as analysis, design, coding, testing, and validation. While this sounds very much like the waterfall phases outlined in our last blog, the difference is that each backlog item moves through these phases individually and quickly, thanks to their small size. As a stakeholder, you will be kept up-to-date about what the team is working on and when you can expect to see new functionality.
A note about sprints
A sprint, or an iteration, is a timebox in which the team completes a set of backlog items. Not all Agile teams work in sprints, and sprint length varies depending on the team, but are usually two weeks long. At the beginning of a sprint, the team identifies high priority work from the backlog that they can complete and commits to getting it done. Once the sprint starts, it’s important for priorities to remain stable, meaning that the work pulled into the sprint can’t be switched out for other work. This allows the development team to focus on finishing a set of backlog items without interruptions or distractions. The backlog priorities can still be updated at any time, until the beginning of the next sprint.
Step 5: Review and Feedback
Once the team has completed an item or a set of items from the product backlog, the work will be presented to the stakeholders for review. This is usually a live demo, but it can also be just a notification that new functionality is available for you to look at yourself. You can expect that, unless noted otherwise, the completed work is fully tested and functional.
If you and the other stakeholders are happy with the work, great! The team will move on to the next items on the backlog. Otherwise, any requested changes are entered into the backlog as new items are prioritized along with everything else left to do.
Reviewing completed work and providing feedback is your most important responsibility as a stakeholder. The team needs to know if they have built the right feature.
The team also needs your negative feedback. It’s always nice to hear what you like, but it’s also important for them to hear what misses the mark, in order to course-correct and improve. Early and regular feedback is crucial to the Agile approach.
Evolving the backlog
The backlog changes constantly. Items are added, deleted, rewritten, re-estimated, and reprioritized. The backlog is a living artifact that is updated as work is completed, feedback is gathered, new information is acquired, and new ideas are generated. It becomes a sort of wish list, rather than a set of rigid requirements.
As a stakeholder, you can always request that new items be added to the backlog. Be prepared to answer questions about how important those new items are to you in comparison to the others. Remember that adding something to the backlog means bumping something else down in priority.
Step 6: Adaptive Planning
To predict when the project will be ready for a release or another milestone, the project manager will create a plan based on the pace of development and how much remains in the backlog. The PM will use this plan to forecast either a date by which a determined scope (set of backlog items) can be completed or how much scope can be completed before a determined date.
If the forecast shows that the desired scope can be completed for the desired date, then no changes are required. If things change along the way, the plan is updated to reflect the changes, either by decreasing scope or pushing out the date.
Although you will have visibility into the plan early, it’s important to remember that it will inevitably change. Some flexibility in scope or time is absolutely necessary for any development team to deliver high-quality work.
The Bottom Line
The point of Agile is to start by building something small and simple, validating early and often that it’s the right thing or heading in the right direction, and then iterating by improving on it or adding more to it. This is in opposition to more traditional approaches like waterfall, in that stakeholders don’t have to wait until the end of a project to see the work. You are part of the process, and you have visibility into real, measurable progress. You can change your mind as you also learn about your product and its users along the way. By playing an active role in the process, you can help ensure your product's success.
