In this post, we are going to focus on the execution phase. After a successful alignment phase, the team – now composed of WillDom members and the clients – is ready to start with estimations, sprint planning, and roadmap creations, followed by sprint executions, demos, and retrospectives meetings.
One big challenge at this phase is that Agile Methodologies* are well known by almost every development team in this current era, but not every team interprets and implements these methodologies the same way. Every team and implementation has its own “twists” so getting to know each team member’s way of doing things and arriving at a common consensus is the stepping stone of this phase.
Execution phase main components are sprint planning, sprint execution, demo, retrospective and documentation, and both technical and executive summaries. Let’s go deeper in each of them:
- Early Effort Estimation for Success: Initial phases like phase 0 (pre-feasibility) or phase 1 (building a roadmap) may carry a question: How to secure estimates in early stages of an agile teams (AT) project when you don’t have your whole team assembled or don´t have all the information gathered?
First of all, keep in mind that there is a secret (that shouldn’t be) for the estimation process: is that estimates are…estimated.
Secondly, your lead – the business – often addresses very general and high-level requirements during the initial stage, and asks for a quick estimation of the project where some requirements are unclear or unforeseen.
The estimations are more accurate and closer to reality if more details on the requirements could be available. If this is not the situation, you can count on the t-shirt sizing technique or with more details in hand use the planning poker technique.
- Story Points Estimation, Release Plan and Sprint Planning: According to Mike Cohn, contributor to the Scrum software development method and founder of the Scrum Alliance, most agile teams are concerned with only the three innermost levels of the planning onion.
Release planning considers the user stories or themes that will be developed for a new release of a product or system. The goal of release planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project.
Release planning occurs at the start of a project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release.
One more thing, the more frequently the teams measure by repeating this process, the better they get at predicting. So for new projects with new teams, this might take a while.
- Effective Sprint Planning Sessions: Every Team member has an important role in defining the sprint goals and the work each member will do to achieve those goals. Key team roles include the following:
- Scrum Master: Facilitates the activity.
- Product Owner: Keeps the team accountable to the project vision and roadmap.
- All Team Members: Prioritize user stories and commit to the sprint backlog.
Through discussion with the product owner, the developers select items from the product backlog to include in the current Sprint. The scrum team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a sprint may be challenging. However, the more the developers know about their past performance, their upcoming capacity, and their “definition of done” (DoD), the more confident they will be in their sprint forecasts.
The product owner proposes work for the sprint in prioritized order by pulling items from the product backlog into the sprint backlog. Later, the team members use the sprint goal and your team’s capacity as decision filters for work to include on the sprint backlog.
Determine the DoD by defining when backlog items are considered complete for this sprint. This is related more to the progress of the work, rather than the outcome. The DoD creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a product backlog item does not meet the DoD, it cannot be released or even presented at the sprint review. Instead, it returns to the product backlog.
Defining the level of confidence in achieving the goals and delivering the work on time is crucial for all stakeholders. Consider team member capacity, and dependencies and risks discussed. The team will vote 1 to 5, 1 being impossible to reach and 5 fully achievable. Anyone voting one or two shares his or her thoughts on how the plan can be improved and discusses for a resolution. Once everyone is aligned, no more user stories should be added to the sprint backlog. If there’s a need to add work, ask if it can be done in the next sprint. Alternatively, remove something that is the same amount of work from this sprint backlog to accommodate the new request.
Once the sprint begins it is very important to make sure your sprint goal and sprint backlog are visible to everyone so everyone stays on course with a common and clear goal in mind.
- Fruitful Demos: The demo marks the end of the sprint and is therefore, in part, a celebration. The purpose of the demo meeting is to inspect the outcome of the sprint and determine future adaptations. The scrum team presents the results of their work to key stakeholders and progress toward the product goal is discussed.
Demo day is one of the most exciting parts of agile, and something teams and stakeholders should look forward to. Now that you know what you’re showing off, and you know how to display its value, it’s time for meeting logistics to own the demo and achieve the demo meeting´s goals.
Last but not least, feedback from stakeholders is a key part of the demo, and is just as important as showing the team’s work. Don´t forget to ask for feedback.
- Insightful Retrospective Meetings: The purpose of the sprint retrospective is to plan ways to increase quality and effectiveness. The scrum team inspects how the last sprint went with regards to individuals, interactions, processes, tools, and their DoD. The scrum team discusses what went well during the sprint, what problems it encountered, and how those problems were (or were not) solved.
In the retrospective meeting, agile teams look for:
- Look back: The team considers what worked, what didn’t, and how to improve. In three columns: “What went well?,” “what didn’t go well?” and “what can we improve?”
- The entire picture: This is where the perspective comes in. Each statement is read aloud, starting with “what went well?” and so on. Everyone is reminded of the established ground rules, and then invite the team to comment or disagree with the observations
- Look forward: Plan how to improve in the future. The teams decide what key improvement areas to focus on. At WillDom we recommend keeping the list short to make goals attainable.
Stay tuned for part 4 where we’ll be discussing the Evolution stage. Until then, we encourage you to visit us at willdom.com or follow us on Linkedin for more information about us.
