Implement Phase of a Scrum Project

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK™). After the Plan and Estimate phase comes to the Implement phase.

This phase includes three processes related to the execution of tasks and activities—creating various deliverables, conducting Daily Standup Meetings, grooming the Product Backlog at regular intervals—to create a project’s product. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.
Create Deliverables
In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint deliverables. A Scrum board is often used to track the work and activities being carried out. At the end of each Sprint, a product increment or deliverable is completed. The deliverable should possess all features and functionality defined in the User Stories included in the Sprint and should have been tested successfully. As the Scrum Team executes the work of creating deliverables according to the User Stories in the Product Backlog, they carry out the mitigating actions that have been defined to address any previously identified risks. The team documents any newly identified risks and mitigating actions taken. The record of project risks is a living document, continuously updated throughout the project by the team.
Conduct Daily Standup
In this process, every day a highly focused, Time-boxed meeting—referred to as the Daily Standup Meeting—is conducted. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing. Daily Standup Meetings propagate the idea that each member of the team is important and is a major contributor, which improves individual and team morale. This, along with the concept of self-organizing teams, improves overall motivation, leads to enhanced performance of the team and improves the quality of deliverables produced.
Groom Prioritized Product Backlog
In this process, the Prioritized Product Backlog is continuously updated and maintained. Remember, the Prioritized Product Backlog contains a prioritized list of project requirements written in the form of Epics, which are high-level User Stories, and is based on three primary factors: value, risk or uncertainty, and dependencies. A Prioritized Product Backlog Review Meeting may be held in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog, as appropriate. The Prioritized Product Backlog may be updated with new User Stories, new Change Requests, new Identified Risks, updated User Stories or reprioritization of existing User Stories.
Following the three processes of the Implement phase will guide effective execution of the project at hand. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Implement phase, however, it is imperative to follow the blueprints of earlier phases to produce quality deliverables.

It is widely known in the software development industry that Agile values “working software” over “extensive documentation.” This leads to the common misconception that Agile does not believe in documentation. It is true that documentation in Agile does not always mean typing code descriptions or lengthy time-consuming information that may come in handy sometime in the future. However, Agile does not condone little or no documentation—Agile encourages the “right” documentation.

Agile encourages “just enough” documentation as is required for the project.  This documentation can be in the form of flip-chart notes or writing on a whiteboard

. Then, one could take pictures of the documentation with a digital device and store it for reference. Agile does not believe in the documentation just because someone feels that each and every detail of the project has to be captured in writing in order to retain knowledge for the future. The aim of Agile is to be better and faster. “Just enough” documentation helps to save time and cost during the project development process.

However, for projects that demand descriptive documentation, such as projects related to armed forces and defense, Agile practitioners are required to document necessary data and information. When documentation adds value to the customer, it is accepted and worked on using the Agile methodology.

Another misconception surrounding the Agile method is that this approach involves no planning. On the contrary, Agile involves planning as much as any traditional approach does. However, its take on planning is different from other methodologies; Agile focuses on getting started with familiar architecture and requirements rather than spending crucial time on setting up a long-term plan. The Agile manifesto emphasizes “responding to change” over “following a plan.” Owing to this value, an Agile team can adjust and accommodate changes in the project plan much better than other traditional teams. Along with planning, Agile also accepts its limitations in a blustery situation.

Agile planning is not a rigid structure but a progressive one. Laying out a strict plan before the initiation of a project may look organized, but is most likely to become a hindrance in the long run because plans tend to change as the team begins to learn from feedback and iterations. Agile planning is based on the project features and is systematically organized into iterations with a time frame of one to two weeks. Agile believes in implementing a short plan efficiently rather than wasting efforts on preparing an elaborate plan that may not be successful in the end.