8
Agile Project Management Process
Although there is some variation in many of the agile methods, there are overall activities common to all of them. Figure 8.1 illustrates the entire framework of the agile project management process at a high level. One can expect to see all, if not most, of the processes in the different agile methods. We now provide a detailed overview of the processes within the agile project management framework. We start with a discussion of the agile project feasibility study which is the initial stage in the agile project management process. A discussion follows as outlined in the diagram.
AGILE PROJECT MANAGEMENT
In order to put the agile project management process into the proper perspective for our readers, we have provided a summary of the differences between agile methods and traditional project management as outlined in Table 8.1.
PROJECT FEASIBILITY
The best way to determine if a project is feasible is to conduct the proper assessment prior to the project start. The project under review for selection needs to be worthwhile and there needs to be adequate justification for the project in terms of what it will bring to the business in terms of value. The agile project with its value-driven approach will display results early and this in turn proves the worth of the project to the stakeholders.* The project feasibility process has two activities and a discussion follows:
FIGURE 8.1
Agile Project Management Process.
Create business case.
Project vision.
Create Business Case
Business case development is usually organization specific and the intent is to justify why a particular project must be undertaken based on the needs of the business. A business case for an agile project is similar to one that is developed for a traditional project; the difference will be the light documentation and the heavy focus on early business value, which is not very common for the traditional project. *
TABLE 8.1
Summary of Differences between Agile and Traditional Project Management
Agile Methods |
Traditional Project Management |
|
Focus is on |
People |
Processes |
Documentation Level |
Low, only as required |
High |
Process Style |
Iterative and incremental |
Linear |
Initial Planning Requirements |
Low |
High |
Requirements Prioritization |
Based upon business value and regularly updated |
Fixed within the project plan |
Quality |
Customer focused |
Process focused |
Organization Style |
Self-organized |
Managed |
Management Style |
Decentralized |
Centralized |
Changes |
Backlog updated |
Formal change management in place |
Leadership Style |
Collaborative; servant leadership |
Command and control |
Performance Measurement |
Business value |
Conformity to the project plan |
Return on Investment (ROI) |
Early and throughout the project life |
End of the project life |
Customer Involvement level |
High and throughout the project |
Involvement level is varied and depends upon the project life cycle |
Source: SCRUMstudy, 2013.
Project Vision
The project vision is a simple statement that represents the goal for the agile project. It is the responsibility of the Product Owner to create the project vision along with input from the agile team. A vision statement should be established that describes what the project should achieve, why the project is being undertaken, and what the definition is for project success.
AGILE PROJECT INITIATION
As illustrated in Figure 8.1, project initiation is the second step in the agile project management process. According to the PMBOK® Guide (2013), project initiation is the set of activities necessary to define a new project (or phase) and obtain the authorization to begin the project (or phase).* Project initiation has the same intent on all projects; however, the activities are somewhat different between agile project management and traditional project management. The initiation process for agile projects includes the following activities:
Create agile charter.
Assign the project staff.
Develop project backlog.
Create estimates.
Develop road map with story mapping.
A discussion of each activity follows.
Create Agile Charter
The process for creating the project charter on an agile project is similar to the PMI’s traditional project management process: develop project charter.† According to the PMBOK® Guide (2013), this process develops the document that officially authorizes the project to start and gives the project manager the authority to use resources. With regard to agile project management, creating the agile charter requires the creation of a very flexible document that allows the team to respond quickly to changes. There are, of course, differences between a traditional project management charter and an agile charter. For the agile project, the project charter outlines the project objectives and expected outcomes of the project. Instead of authorizing just the project manager as in traditional project management, the agile project charter authorizes the entire team to start the project.‡ Other differences between the traditional and agile charters may include the following:
• There is very little detail in the agile charter.
• The charter needs to specify the agile method so that everyone is on the same page. This applies in the case where there is a change in the agile method or agility is new to the organization.
• Agile charters are smaller than traditional project management charters.
• The agile charter has to allow for changes throughout the project.
• The agile charter answers the Five Ws and the One H questions (who, what, why, when, where, and how).
The Five Ws and the One H questions were written by Rudyard Kipling, a novelist, writer, and poet who was born in Bombay in 1865 and died in 1936. The poem is titled “I Keep Six Honest Serving Men.”*
I KEEP SIX HONEST SERVING MEN
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
I send them over land and sea,
I send them east and west;
But after they have worked for me,
I give them all a rest.
I let them rest from nine till five.
For I am busy then,
As well as breakfast, lunch, and tea,
For they are hungry men:
But different folk have different views:
I know a person small—
She keeps ten million serving-men,
Who get no rest at all!
She sends ‘em abroad on her own affairs,
From the second she opens her eyes—
One million Hows, two million Wheres,
And seven million Whys!†
The Five Ws and One H in the poem are considered to be a problem-solving method referred to as the “Kipling Method.” This method helps explore problems by using the six questions as a starting point in getting answers.
Assign Project Staff
The process of assigning the project staff consists of obtaining the agile team (i.e., developers, Product Owner, and agile leader) necessary to complete project activities. The agile team needs to be cross-functional and capable of working under time-boxed constraints to deliver a high-quality product. Value to the customer must be built quickly and delivered frequently. In addition, the product’s quality needs to be validated by means of verification and validation activities.
The agile team has a number of responsibilities that need to be achieved. The desired characteristics of an effective agile team include but are not limited to the following traits:*
• Self-managed: The agile team should be able to function effectively in a self-regulating environment.
• Colocated: Agile teams work better when everyone is physically in the same location.
• Small team: The agile team should “typically” not have more than 6-10 members.
• Single backlog: The agile team should work from only one backlog.
• Commitment: The agile team should be committed to building and delivering a high-value product.
• Communication: The team must be effective with face-to-face communications.
• Accommodate change: The agile team should be able to embrace changes and accommodate unplanned work.
• Create reasonable estimates: The team must be able to create reasonable estimates for the work that they agree to complete and must deliver what they agree upon.
• Continuous improvement: The team must continuously find ways to improve its performance.
• Cross-functional: The team members must be cross-functional and have the capability to perform in multiple roles as needed.
• Sustainable pace: The agile project team must be able to maintain a sustainable pace throughout the project.
Develop Project Backlog
The agile team’s main focus is to plan to deliver high-value features as early as possible and at the same time avoid or mitigate risks. During the planning phase, the product backlog is prioritized based on the product’s features that have the greatest value and/or the highest risk levels. Epics (large user stories) are created during the beginning of the projects when requirements (user stories) are very high level* and have not yet been decomposed enough for the development team to work with. Because the epics are originally too large during project planning, they are broken down, clarified, and prioritized to create the initial product backlog for the project. The Product Owner is responsible for prioritizing the user stories in the backlog.
Create Estimates
There are many techniques that are used on agile teams to create estimates. We discuss several of the most common estimating techniques.
Affinity Estimation†
This is the process of positioning the requirements into groupings. On the agile project, this method is used to place similar sized user stories together in the same group so that a proportional view of the estimates can be obtained. When the team places the user stories into groups based on size, it provides an opportunity to see if they have been accurate with similar estimates. This technique ensures that the size of a story point remains consistent throughout their estimates. The approach for this type of estimation is to create columns on a task board for different requirements and then place the user stories in the columns that match the “size.”
TABLE 8.3
Fist of Five
Number |
Meaning |
Description |
1. |
One Finger |
Team member disagrees with the group’s conclusion and has major concerns. |
2. |
Two Fingers |
Team member disagrees with the group’s conclusion and wants to discuss minor issues. |
3. |
Three Fingers |
Team member is not sure but wants to go with the group’s consensus and conclusion. |
4. |
Four Fingers |
Team member agrees with the group’s conclusion and wants to discuss minor issues. |
5. |
Five Fingers |
Team member agrees wholeheartedly with the group’s conclusion. |
This will determine if the story point sizing method is valid. Table 8.2 shows an example of how this process should be conducted.
Fist of Five:* This agile estimation technique is based on gaining group consensus. A discussion or proposition is presented to the team and each member is asked to cast a vote based on a scale of one to five. Team members use their fingers to display their votes. In addition to gaining consensus, this technique also facilitates discussion among the group. After a team discussion, a united decision is made. The number of fingers raised by each member indicates the level of agreement and/or need for further discussion. Table 8.3 outlines the meaning of each raised finger.
Ideal Time: This technique is based on estimating and omitting interruptions. For example, in an eight-hour business day, all eight hours are not available for working. Lunch, breaks, or time out of the office are not counted in the estimates. Ideal time is not realistic as to what happens in the real world, however, it keeps the estimation process very simple.* This estimation process is very accurate because it only includes actual work time and nothing more. When estimating a user story based on ideal time, work time is calculated based on “no disruptions.”
Story Points: A story point is simply a “relative measurement of work.” The main idea of using story points for agile estimation is to discontinue calculations based on hours worked per week. Why is this so? Hours per week fluctuate for many agile team members and using this measurement is often not realistic. Story point estimation takes very little time, is flexible, and can be easily modified. Agile teams typically create their own definitions for their story points and each team has the freedom to determine the appropriate story point sizes. For clarification, baselines are created after the story point value had been defined and agreed upon by the development team. Once the story point value is established, it will not change for agile iterations. Story points do not necessarily need to add up to a whole when they are broken down. The level of complexity, work effort, and risk should be considered when determining the number of points assigned to a story. Lastly, story point calculations should make sense in that 1 + 1 = 2. This means that two one-point stories should equal out to roughly a two-point story.
Still not sure what story points are? Let’s continue our discussion. As some of us may have experienced, estimating work can be unpleasant, time consuming, and difficult. Readers should recall that agile methods are about simplicity and story points were designed to make things simple. Story points are based upon using a comparative approach to estimating where we base new activity estimates against work that has already been completed. Basically, we are comparing new estimates with prior estimates which is in actuality a very good practice. Readers must understand that the story point estimates are perceived to be better than hours per week estimates on the agile project. Why is this the case? According to Griffiths (2012) when estimating in hours, this can create a fake ceiling. Estimating in hours has the potential to create issues for some workers who have heavy demands on their time and are never able to provide 40 hours of actual project work per week. There are several things that readers need to keep in mind when working with story points.
• The development team is responsible for its own story point sizing definitions. For instance, the team may agree that one story point is equal to one hour; or one story point is equal to one day, and so on. It is strictly up to what the team decides upon.
• The story point estimate should include all activities. Nothing should be left out or added in after the story point has been defined.
• In the case where a story point is decomposed, the total of the individual units is not required to match. This means that when epics are broken down into user stories, it is not required that the totals of broken-down user stories add up to the original size of the epic. Got that? As an example, if an epic is sized as 10 story points and it is broken down into three user stories that equal 2, 3, and 1, respectively, it is OK that the total does not equal 10 and this only applies during the decomposition process!
• Story point sizes should be relative. Simply put, a three-point story point should equal approximately three times the work effort of one story point.
• Story points should include work effort, risk, and level of complexity. The entire time that is needed to do the work should be included in a story point.
4. Wideband Delphi: According to the PMBOK® Guide (2013), the Delphi technique is used to gain agreement among a group of experts.* The wideband Delphi technique is used to gain group consensus for a particular estimation approach.† This tactic gathers a group of experts and asks them to anonymously make estimates. Anonymity is used as a precaution against bias. A wideband Delphi session is initiated with identifying the problem at hand. The project is then broken down into practicable “pieces” in order to be manageable by the group. For example, a problem specification is first created, assumptions and constraints are discussed, and a process for moving forward with successive estimation meetings is developed. The team is allowed to ask questions openly prior to providing estimates. A meeting facilitator collects the estimates from the group based on “rounds” (number of meetings). After several rounds of estimations, the group of experts should begin to reach a consensus on the estimates provided. All of the experts must reach agreement on the final list of tasks and their estimations. The wideband Delphi technique is effective because it considers feedback from all of the experts. The collaborative nature of this technique increases the buy-in phase so that consensus can be ultimately reached by all.
Cost Estimation
In order to determine cost estimates for the agile project, there are several calculation steps that need to take place. A discussion of this process follows:
Calculate the size of the project based on the total number of story points.
This can be done using planning poker or another estimation technique.
Calculate the amount of work to be completed on the project in person-days. We can use ideal time (previously discussed in this chapter). Person-days can then be reduced to hours.
This calculation is done by adding up the availability percentages for all team members and then dividing this result by the total number of team members. For example, if there are four teaming members (Tom, Bruce, Donna, and Mary), the individual availability percentage for each is (100%, 100%, 85%, and 50%). We add these percentages and then divide by 4 to get: ((100 + 100 + 85 + 50)/4 = 84%). If the total ideal time is 800 days to the complete project, we divide 800 days by 0.84 (800/.84 = 952 person-days). If we have four people doing the work, we calculate the work per person (952/4 = 238) person-days.
Determine the project schedule based on the calculated person-days. In this step, we need to take into consideration dependencies or constraints that may affect the number of actual person-days. We now need to translate person-days into months. There are 21 working days (on average) in a month, so we calculate (238/21 = 11.33) months to complete the project.
Calculate the total costs of the project with labor rates and other associated costs.
The formula to calculate is: total cost = (time × resource rate) + (other project costs).
We need the hourly rates for each of the team members (Tom, Bruce, Donna, and Mary). Each of their hourly rates is ($75, $89, $87, and $72), and working 8 hours per day, with an average of 21 days is (8 × 21 = 168) hours per month. Next we calculate the number of project hours, (11.33 × 168 = 1903).
We now plug in the labor costs for each team member. See Table 8.4 for total project costs ($614,669.00).
TABLE 8.4
Total Project Costs
Name |
Rate ($) |
Total Hours |
Total Costs ($) |
Tom |
75 |
1,903 |
142,725.00 |
Bruce |
89 |
1,903 |
169,367.00 |
Donna |
87 |
1,903 |
165,561.00 |
Mary |
72 |
1,903 |
137,016.00 |
Total Project Costs |
614,669.00 |
Develop Road Map with Story Mapping
This is the final process in the agile project initiation phase. The agile term story map is used to describe the method for selecting and grouping product features that are going into a particular release. Story maps show the priority levels of features based on how they have been classified. For example, backbone, walking skeleton, or additional features are classification terms that can be translated into priority levels high, medium, or low. When product features are placed on the story map according to their relative level of importance and order, the customer’s priorities are then put in parallel to what the development team can actually deliver. The end result is that the product’s releases can be identified on the road map as a result of defining the story map. For additional clarification, the story map shows the importance of features based on their order (left to right). The road map, on the other hand, shows in which releases the stories will be. At first glance, the product road map and the story map may appear to be very similar, however, just the opposite is true. The product road map is used to illustrate the product’s releases and the functionality to be developed within each release. In contrast, the product’s story map shows how the features can be grouped for a release. All critical functionality for the system is labeled as the backbone stories and the walking skeleton stories represent those that can create the smallest possible working system. The third and final group of features remaining is prioritized based on their relative importance to the agile team.*
PLAN RELEASE
A release is simply a distribution of the product outside the agile team. This means that the software is released to the end user. The release plan is developed to communicate when the software will be released and what functionality is to be contained within the release. The customer typically decides when the product will be released, however, the agile team is permitted to provide its input. Releases can be date or functionality driven. The release plan is developed for planning purposes and to provide important information to the stakeholders. There are three activities that are typically undertaken during the release planning process. A discussion of these activities follows:
Breakdown epics
Estimate stories with poker planning
Create release plan
Breakdown Epics
Epics are large user stories that need to be further broken down. The breakdown process results in smaller, more manageable, user stories. There is no right or wrong way to break down an epic but a hierarchical approach is recommended with the end result being a task that is estimated by the development team and used to build a product feature. Starting from the epic, user stories are created. From a single user story, several tasks are created. The hierarchical process for breaking down the epic into smaller components follows:
• Epic 1
• Epic 2
• User Story 1
– Task 1
– Task 2
– Task 3
• User Story 2
– Task 1
– Task 2
• User Story 3
– Task 1
Estimate Stories with Poker Planning
This estimation technique is based on obtaining team consensus to estimate the size of user stories. Planning poker starts with all team members being assigned a single deck of poker cards. The cards in each deck are numbered using the Fibonacci* sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, …). The Fibonacci sequence is calculated by adding the two previous numbers to get the next number in the sequence (0 + 1 = 1, 1 + 1 = 2, 1 + 2 = 3, etc.). The numbers represent the estimated level of complexity based on effort and time. The Product Owner leads the estimation game and presents each user story to the development team. Each agile team member evaluates the user story and attempts to understand the complexity associated with it. Each developer then selects a card from his or her deck that describes his or her estimation for the user story being discussed. If a consensus is reached by the majority of the team, then that estimate is used for that particular user story. In the case where there is no agreement on the user story estimation, each team member provides reasons for the selections. The estimation process is repeated until a consensus is reached on the number representing the estimation.† The final number is recorded on the user story as the story point value.
Create Release Plan
The first step in creating an agile release plan is to determine what needs to be accomplished in terms of goals and objectives. Creating the release plan is not done blindly; the business goals and the team’s velocity (capacity) is very relevant during this planning process because the team’s capability drives the release planning and outcome. Speaking of the team’s velocity, this number is determined by how many story points the development team can complete during an iteration. It would take several iterations for the team to obtain an average number of story points that they can complete and this means that the team velocity is only established after such time. The priority of the user stories is also an important factor with regard to what goes into the release plan. A consensus must be reached in terms of the goals of the release plan. The development team must make a realistic commitment as to the amount of work that can be completed for each planned release.
ITERATION 0
The goal of iteration 0 is simply to prepare for iteration 1. According to Scott Ambler & Associates (2012),* approximately the first week or so of an agile project is considered to be iteration 0. This iteration is considered to be the warmup or the inception phase of the agile project. The following events take place during this time frame:
• The project is initiated.
• Support and funding are established for the project.
• Stakeholders are active and participating in the project.
• The team is established.
• The agile environment is created.
• The initial system architecture is modeled.
There are two main activities that are conducted during iteration 0:
Architectural spikes.
Prepare for iteration 1.
A detailed discussion of these activities follows.
Architectural Spikes*
Architectural spikes are iterations that prove specific technological approaches. Risk-based spikes are periods of work that are used to mitigate risks. Spikes are included in release planning. An architectural spike can be either functional or technical in nature and it represents a story that is used to validate the exploration of an idea, a design, or research. The goal of a spike is to acquire information that is required to mitigate the risk of a technology-based approach, gain understanding of a particular product requirement, or validate an estimate for a task(s). A functional spike is conducted to analyze combinations of functional behavior that may need to be broken down or analyzed for risk complexity. This is done so that the correct implementation decisions can be made. In contrast, the technical spike is conducted to validate design considerations. Spikes are implemented during the end of an iteration and are owned by specific team members. In simple terms, a spike is used to eliminate risk within a particular user story. It is important to understand that a spike is not adding value for the customer and should be used cautiously. On the other hand, if an opportunity can be created from a spike, it would be considered to be adding value.
For clarification, an architectural spike is an iteration designed to prove a technological approach and spikes are work done to reduce risks.† There is a concept called a risk-based spike. This type of spike is done so the development team can determine whether a particular technological issue is feasible. The goal of this type of spike is risk reduction, possible cost reduction, and to improve the chances that the project will be successful. Risk-based spikes are used to conduct experiments so that high-risk components of the project can be fully understood and their impacts mitigated. If the experiment’s results show feasibility, the risk is eliminated. This results in the overall project having a lower risk ranking. If the results of the experiment are not feasible, then a different approach is used. If all experiments show results that are not feasible, then this would mean this particular project has a high failure rate and should be abandoned.
Risk-based spikes are used to validate new technologies or those that are unfamiliar. These spikes are done early in the project so that development efforts will not waste money and time in the event that the technology is determined to be too risky.
Prepare for Iteration 1 during Iteration 0
During the preparation for iteration 1, the development team will need to compute its team velocity, excluding downtime (vacations, sick leave, etc.). The main goal of iteration 0 is to prepare the next iteration’s (iteration 1 in this case) user story details. This involves the utilization of several tools and techniques including but not limited to: creating use cases, activity diagrams, data models, sequence diagrams, acceptance tests, business cases, and identifying data fields.* Keep in mind that the agile project is not designed for much up-front planning because this activity is done throughout the entire project. Up-front planning is not done on the agile project because there is very little static information available early in the project. Details on the agile project are discovered along the way and the team must make adjustments as they are warranted. The best way to describe the planning for the agile project is “adaptive.” The team adapts as it proceeds. See Table 8.5 for a high-level view of the iterations as they relate to releases.
TABLE 8.5
Iteration Cycles
Iteration Cycles |
||||||||||
Iteration 0 |
I1 |
I2 |
I3 |
I4 |
I5 |
I6 |
I7 |
I8 |
||
R1 |
R2 |
R3 |
R4 |
R5 |
||||||
Note: I = Iteration, R = Release.
This concludes our discussion of iteration 0. Keep in mind that every agile project is unique and there may be variation in the activities based on the needs and objectives of the project. We now begin our discussion of the preparation of iterations 1 through N (where N is the total number of iterations in a given release).
ITERATION PLANNING 1–N (WHERE N IS THE TOTAL NUMBER OF ITERATIONS IN A RELEASE)
Iteration planning involves deciding upon the high-priority user stories that will bring the most value to the customer. The iteration planning goal should be established (i.e., the number of user stories to be completed during the iteration), however, if the project is a first, the team velocity may not be established yet. Remember, the team’s velocity can only be established after they have completed several iterations and have obtained an average number of story points that can be accurately defined as its capacity (velocity). In any event, the development team is empowered to decide on the number of user stories for the iteration and they must discuss their recommendation with the customer.
During the iteration planning meetings, the customer (or Product Owner) has the ultimate responsibility for prioritizing the product backlog and indicating to the team which user stories she would like to see in the iteration. The agile team will then select a set of user stories from the backlog that they feel can be completed in the iteration. The customer establishes the priorities for the iteration, however, the development team has the final say on the amount of work they believe they can complete for the iteration. An iteration backlog is the plan that the development team works from to deliver the product for the iteration. Iterations 1–N are considered to be development iterations and the goal is to deliver system functionality that meets or exceeds the customer’s expectations. The agile team delivers the product in increments. Test-driven development (TDD) activities, an XP concept explained in Chapter 3, are conducted to confirm the validity of the user stories. The team works collaboratively and the product is internally deployed for acceptance. Stakeholders are very participative and provide feedback as deemed necessary. Keep in mind that iterations are time-boxed into approximately two-week time frames. There is never an infinite amount of time to complete an iteration.
Iteration R
The purpose of iteration R is to deploy the product to the production environment. This iteration is separated from iterations 1–N (where N is the total number of iterations). Why does this separation occur? It occurs so that the development team can continue to build functionality for the next release and in order for the current release to be moved to production. Keep in mind that in the case of a final release, there would not be any continued development activities. The following activities occur during iteration R. The development team, of course, takes care of all iteration R activities:
• Complete project documentation.
• Formal testing (security, performance, integration, or regression).
• Deploy the software to production.
• Celebration, Celebration, Celebration!!!!!
Coding
The Agile Manifesto and its guiding principle state: “Build projects around motivated individuals; give them the environment and support that they need and trust them to get the job done.” According to Ambysoft, Inc. (2013),* a common best practice on the agile team is to provide the development team with sandboxes in which to develop code. What is a sandbox? It’s just a fancy name for a respected technical development environment with a “well-defined scope.” How’s that for fancy? Ambysoft further indicates that the sandbox reduces risk because it protects against technical errors. There is less worry on the agile development team because access is limited, which results in fewer mishaps. Specific categories of sandboxes include:
• Development Sandbox: Development environment where only the development team has access to develop the code for the product.
• Integration Sandbox: Build environment from which each project team works. Code is integrated from all of the development activities to ensure it will work well when integrated.
• Demo Sandbox: Working code environment where demos can be carried out for the client.
• Preproduction/Test Sandbox: Staging environment that is generally a replication of the live production environment. Systems testing is executed in this environment prior to the release to production.
• Production: This is the live environment for the completed product.
Execute Acceptance Tests
The purpose of the acceptance test in the agile environment is to ensure that the product meets the requirements from the customer’s perspective. These tests are designed to verify the functionality of the product based on actual demonstrations. On the agile project, the customer or their representative performs the actual testing to ensure that the product performs as expected. In addition, acceptance testing (or user acceptance testing) is executed during development iterations.*
Many agile projects conduct what is known as acceptance test-driven development (ATDD).† This type of testing focuses on the business requirement rather than the code. Test cases are created prior to code development and are designed to demonstrate the product’s functionality for the customer’s acceptance. Prior to the creation of an acceptance test case based on a user story from the backlog, the customer clarifies the desired behavior. There are four steps to the acceptance test case and demonstration process.
The requirements are discussed and the customer is asked questions so that the proper acceptance test can be developed.
The acceptance test cases are entered into an acceptance testing tool.
Code is developed and acceptance test cases are attached and executed. If the code is attached to the correct tests, the expectation is that the test will pass; otherwise, if not attached correctly, the tests will fail.
The development team demonstrates the software to the customer using the automated acceptance tests.
Create Test Cases
Agile projects use test-driven development to create test cases. Test-driven development requires that the development team envision how the product’s functionality works prior to the creation of the code. Tests are then typically written in a unit testing language such as JUnit. The initial test will fail merely because the code would not have been created yet for the functionality. The development team writes code and runs the test case until the code has successfully passed the test.
Execute Automated Testing
Automated tests are used for test-driven development and acceptance test-driven development. TDD, an XP concept, is used to implement coding and testing cycles to ensure that the code functions as intended. The test is developed before the code. When the code actually passes the test, the functionality is considered to be completed. On the first run of the test, failure occurs because the code has not yet been developed. A cycle of test execution and writing code is repeated until the test passes. Development efforts continue in the case where additional functionality is needed; otherwise when all tests pass, the code is then refactored. ATDD focuses on the business requirement rather than the code. This means that these types of automated tests are used to demonstrate that functionality is acceptable to the customer. These tests are also written prior to the development of the code. TDD and ATDD have been reiterated in this book because they are important concepts of agile methods.
Definition of “Done”
Agile methods place great emphasis on defining what “done” means and having all stakeholders (i.e., executive management, sponsor, managers, agile project team, users, etc.) agree on what the word looks like for the project. A simple but effective way to define what “done” means is to document the criteria that define what is meant so that everyone is clear on its meaning. Done could describe the following conditions or a combination of conditions such as:
• All stakeholders are in agreement that everything is done.
• All issues have been resolved.
• Customer signoff has occurred on all user stories for an iteration and/or release.
• Testing is completed.
To summarize, the criteria for done should be agreed upon, recorded, and approved by all stakeholders.
Answer Client’s Questions for Sign-Off
At the end of the development iterations, the customer and project stakeholders gather for a meeting to review the prioritized backlog items. The product’s functionality is validated and participants ask questions and provide feedback. The customer has the final say as to the acceptance or rejection of a requirement (user story from the backlog), however, the decision is based on the previously established acceptance criteria. The customer does not have the authority to change the agreed-upon acceptance criteria once the iteration is underway. Once the customer agrees that the user story is done, the prioritized backlog item is signed off on either verbally or in writing based on the practices of the customer organization.
Prepare Stories for Next Iteration
The preparation of user stories is simply to outline requirements for the product’s functionality. In the case of Scrum, for example, a user story should provide the following information:*
• Who?: Represents the user role executing the functionality
• What?: Represents what the user role should be able to perform in the system
• Why?: Represents the reason why the user needs to perform the desired function in the system
See Table 8.6 for an example of a user story based on the Who, What, Why format described above.
As a <role>, I should be able to <requirement> so that <benefit> |
User Story Example: |
(1) As a customer, I should be able to send an e-mail to the bank so that I can communicate quickly and easily. |
(2) As a vendor, I should be able to create an estimate so that I can show the client how much iterations will cost. |
Daily Standup Meeting
As discussed in Chapter 3 under the Scrum framework, the daily standup meeting is time-boxed to a maximum of 15 minutes. One may contemplate how a meeting can be conducted in such a short time frame. The answer is that each team member (typically just the development team) is asked three questions:
What have you worked on since we last met?
What do you plan to complete today?
Are there any obstacles in the way of completing your work?
Update Burndown/Burnup Charts
Both the Burndown and Burnup Charts are used to show how much progress has been made on the agile project. The Burndown Chart reveals the amount of remaining work that needs to be completed and the Burnup Chart reflects what has been delivered for the product. These particular charts can be tailored to show progress based on time or the number of iterations. When using iterations as a measure of progress, story points show scope levels per iteration. When using the amount of time as a measure, then these charts show the approximate amount of time remaining. Important to note is that these charts can be created in Microsoft Excel.
Iteration Retrospective
Many of the agile methods conduct retrospectives as a way to learn, to reflect, and to provide the foundations for making improvements in the agile process. The retrospective meeting occurs after a single iteration and the agile team members convene to discuss ways to improve their techniques. A benefit of the retrospective meeting is the fact that it occurs during the agile project and there is time to implement the lessons learned information on the current project. The process of reviewing lessons learned throughout the project is very beneficial because the team has the opportunity to:
• Improve its performance by increasing productivity.
• Improve on knowledge attainment by sharing information.
• Improve on product quality by undermining the cause of defects.
• Improve on making processes more efficient which in turn will increase team capacity.
The iteration retrospective is typically time-boxed for two hours and it is process driven with five major phases.*
Establish the stage: Focusing the participants on discussing the events of the last completed iteration. Encourage the team to speak up and remain engaged throughout the meeting. Give everyone a chance to contribute. Create a master list of issues for the team to work from. Prepare for the next step in the process.
Compile the data: Compiling the data based on the events that occurred during the iteration.
Create insights: Giving the participants an opportunity to evaluate the information gathered (brainstorming, etc.).
Decide upon what needs to be done: Giving the team an opportunity to decide on what they need to change for the next iteration based on the events from the last completed iteration.
Close the retrospective meeting: Reflections, expressions of thanks to each other, document and validate any team ideas as appropriate. Discuss what went well, what went wrong, and so on.
This concludes our overview of iterations 1–N and the activities that occur during these phases of the agile project. Once all the iterations have been completed for a release, there is an option to begin a new release and the iterations begin once again. After all the releases have been successfully completed, the product is delivered to the customer. We now turn our attention to what happens after the agile project is complete. As in traditional project management, the agile project must be properly closed out. A discussion of close-out activities follows.
CLOSE-OUT ACTIONS
A main focus of conducting close-out activities for the agile project should include a celebration for the purpose of showing appreciation to the team members for completing a successful project and for formally ending the project. Celebrations are also good for keeping morale levels high among the team members during this transition period. During this stage of the agile project, documentation should be finalized for administrative and financial reporting requirements as applicable. A “project retrospective” should be conducted for the purposes of documenting and sharing information from the team’s knowledge base. Any lessons learned information, both good and bad, should be shared by the project team so that others may use this information to learn from on future projects.
CHAPTER SUMMARY
Agile project management is an iterative and incremental process that is used for new product development, information technology, engineering, and the like. Agile methods are very flexible, transparent, and adaptive. The agile project management process supports changes and consistent stakeholder involvement. The project management role is shared between the entire agile team which is in contrast to a single project manager in the traditional project management role. What a difference!