Business Visioning: Identifying Customer Value

As teams begin a value delivery lifecycle, they need to provide a means to capture customer ideas and prioritize and rank them to ensure they are building something the customer wants. Ideas primarily come from the customer, but they may be channeled through discussions with sales, presales, marketing, management, and others. With a business visioning idea-capture tool, ideas can come directly from the customer into this customer-facing tool and be sorted out by the Product Owner.

It is advantageous to provide an idea generation and collaboration space with web conferencing that is both threaded and traceable from the source to the idea. This provides customers a place to submit ideas that may evolve into epics or user stories. The latter implies integration between idea generation and user stories in the Product Backlog.

A key to business visioning is having the ability to generate market-level objectives from ideas so that a team has a vision of what they want to build yet remains adaptable to the ever-changing marketplace. Then they should have the ability to generate a business case from the ideas, market objectives, projected return on investment, and market analysis.

Collaboration: Sharing Customer Value

A collaboration tool is a virtual replication of an Agile Team room. This is a virtual room that can be viewed from your computer, in which you can see the rest of the team in action. You can “poke” them, have a discussion, break out into individual virtual team rooms, view the story wall, and see your specific work wall.

Team members need to enable continuous communication among themselves with threaded team conversation. These conversations need to be integrated and connected to certain events (such as Sprint Planning and Daily Scrum) or certain work items (such as user stories), so that they can be available for considering context and further detail as needed.

Full project teams and their Scrum Team components also need the ability to support Scrum of Scrums (SoS) for collaboration and discussion. There may be a project SoS (when there are multiple Scrum Teams on a project), Product Owner SoS, and technical SoS. Each may benefit from collaboration space.

From an external perspective, having the ability to initiate virtual customer validation sessions (such as Sprint Reviews) to demonstrate Sprint functionality from the version control or testing environment is enabled by an agile ALM solution. Feedback from virtual attendees can be captured in the collaboration system and agile tools related to specific stories and Sprint. This input should be readily available for the next Sprint Planning session.

Agile Planning: Capturing and Prioritizing Customer Value

A team, led by the Product Owner, needs the ability to establish and manage a Product Backlog to capture epics, user stories, and tasks and then establish relationships among them (from tasks to their parent story, from stories to their parent epic or theme, and so forth). Agile Planning tools must have the ability to capture:

• Product Backlog Item (PBI) types, such as epic, theme, user stories, tasks, and bugs
• unique identifiers for each PBI
• the originator or source of the PBI
• the priority of the PBI
• dependencies the PBI has on other PBIs or external functions
• the Sprint in which the PBI is built
• comments regarding the PBI

Chapter 18 discusses agile planning tool needs in the context of the Product Backlog and attributes.

The good news is that this functionality is readily available in various tools. Within the context of managing a backlog, a team needs the ability to ­generate Sprint Backlogs from the Product Backlog based on priority—including the ­ability to capture acceptance criteria related to a story, ensuring that the Sprint story wall is in a visible place.

It is also advantageous for an agile planning tool to capture customer ­personas. This is useful when a team’s requirement language construct (such as the canonical form) captures the persona. You can create the customer personas for your specific product; then, when the Product Owner is writing the user stories, they can be linked to the persona details.

As a result of backlog management, having a means to generate Sprint Burndowns, release burnups, and Sprint and release velocity metrics in an automated manner helps the team track progress. When Agile is being ­implemented on large project teams with multiple Scrum Teams, it is beneficial to get a cross–Scrum Team view of the Sprint and release progress.

The last session within a Sprint is the Sprint Retrospective. It is beneficial to have the ability to support the retrospective process and merge the improvement tasks back into the Product Backlog for Sprint Planning. These tasks can be included in the next Sprint and tracked to closure.

Defect Tracking: Identifying Bugs While Increasing Quality

Defect tracking tools provide a team with the capability of documenting, prioritizing, and tracking defects to closure. As part of the Sprint, teams often incorporate defect work. Because of this, they need the ability to track defects related to the product. In addition, the Product Owner must have the ability to selectively include defects into the Product Backlog as appropriate. This is especially relevant to legacy products.

Teams also need the ability to differentiate clearly among the defects associated with the current Sprint, past Sprints, and past releases. This implies integration between the defect tracking tool and the agile planning backlog management tool.

Version Control: Identifying and Controlling Assets That Form the Basis of Customer Value

A version control tool provides the ability to store, manage, and track changes to source code. There is a need for a version control system that can manage any type of element, such as code, documents, test scripts, and executables. These elements form the basis for the assets that must be managed. These code assets require the ability to be tagged to a release of the product.

The version control system should have the ability to form private workspaces so each team member can work securely in a “sandbox,” allowing for both creativity and integrity prior to promoting code to the project level or backing stream. To support different code levels and streams, the version control system needs a robust branching and merging process to support different lines of development of working code while the assets that represent customer value can be clearly identified and tracked.

Because assets are important to delivering customer value, the version control system must be regularly backed up, along with a tested disaster ­recovery process with quick turn-around time for recovery. The version control system forms the basis for the continuous integration and build system so that what is built comes directly from a location of known integrity.

Continuous Integration and Build: Continuously Building Value

Continuous integration and build refers to the process of checking in and merging code from a developer’s private workspace to the project stream, thereby immediately initiating a project-level build. Key advantages are that the team learns of merge and build issues right away. Frequent code merging reduces the challenges and pain of large, complex integrations in the future. It also provides team members with immediate feedback on the success or failure of changes in a build and in the subsequent smoke test of the product. The smoke test provides a brief test of the functionality to ensure it operates at a basic level.

A continuous integration and build system should be integrated with a version control system that provides effective branching and merging functionality. This includes the ability to initiate merge and build on check-in to the parent branch and to provide information on what was merged and built and their results. In addition, it is beneficial to have an integration with the agile planning tool on one end to make the team aware of the merge and build results and on the other end with the test environment to initiate the next step in testing.

One of the advantages of continuous integration is that the team begins to build the customer value early and often. A very interesting cultural shift occurs when the concept of continuous is ingrained into a culture. Agile embraces a mindset of continuous change in which builds move from an event-based integration process to a continuous integration process. In other words, no one needs to hold onto large amounts of changes for a major integration effort. It also promotes more granular user stories and more frequent code changes.

Testing: Verifying and Automating for Quality

Although prioritized scope drives customer value, teams need to ensure that value is of high quality. The test function is important to Agile. Testing comes with a whole range of tools. The ability to run functional tests, system tests, regression tests, performance tests, load tests, and others are critical to ensuring product quality. Integration with the agile planning tool allows the team to be aware of test results, including what tests were successfully run on stories.

In addition, establishing a test automation framework allows for reduced QA and developer involvement and allows for the tests to be continuously run. In Agile, automation helps reduce manual testing, which slows the team down. As automation is added, a focus on quality data can help a team highlight opportunities to increase velocity and improve quality. Details on test tools should be included within the QA vision discussed in Chapter 15.