Product Management

Introduction to Software Product Management

guide the development of a software product from inception to delivery。

how to understand and refine the software requirements of a client.

how to communicate those requirements to a team of developers.

learn techniques for monitoring your projects to ensure they align to client needs.

describe the role of a software product manager.

Explain what Agile software development is all about.

An effective software product manager is a good listener. Someone able to imagine a valuable product, from users who may not fully express or appreciate their own needs.

Product Management vs Project Management

A software product manager needs a unique set of skills to assess whether the product is meeting client expectations, and to work with a development team to solve the client’s problems.

Goals to Achieve The Better Software

• One viewpoint aims to provide the right software product for the clients. That is, it meets their needs, solves their problem, and they are happy with it. That is, the software product is validated.

• A second viewpoint aims to have the software product done right. The software implementation conforms to a specified design, and in turn, the design satisfies a stated set of requirements. Developers can conduct reviews and tests to ensure the requirements, design, and implementation line up and do not have defects. That is, the software product is verified.

• A third viewpoint aims to have the software project itself managed right. The idea is to adopt just enough process and suitable practices to organize the work of everyone involved. These practices ease communication and feedback, so that everyone is clear on the next steps. That is, the project is managed.

Consequently, to achieve better software, three goals are: the right product, done right, and managed right.

Role of Software Product Manager

A software product manager is in charge of the success of a software product. But the role is much more than managing a project. Great software product managers can speak to both clients and developers in their own terms. The role involves understanding the product from the client’s point of view. The role also requires effective communication and motivation of development team members.

Defining Project Success

Developers spend countless hours and sleepless nights thinking about the best way to design software. Their efforts directly impact the parameters for measuring project success:

• On-time delivery
• Completed within budget
• Delivered with all features complete

Project success could also be measured by:

• The number of post-release bugs
• The support needed after a release
• The software product’s customer rating
• The revenue generated
• The client’s satisfaction

A software product manager will help to identify attributes of product and project success and assign metrics to ensure that development efforts are driving towards successfully delivering a quality product.

Manifesto for Agile Software Development

“Agile” is set of software development principles created for effective and adaptive software development. These principles take shape as practices that have become commonly adopted in the software development industry.

Four Core Values of Agile

Four core values define the Agile philosophy for software development.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The Agile philosophy values the items on the left more than the items on the right. This is not to suggest that you ignore processes and tools, comprehensive documentation, contract negotiation, or following a plan. It is merely that the items on the left are the more important things to focus on.

Twelve Principles of Agile

The four core values are illuminated by 12 principles of Agile software development.

Agile software development brings focus to ensuring a steady, manageable, and efficient development pace. It strives to avoid situations where team members are overwhelmed with project tasks.

Agile practices also encourage frequent testing and demonstrations. This helps to reduce bugs and keeps the client involved in the development process, so the end deliverable is a product the client can use.

Agile practices encourage communication with the client. Managing expectations is important. Keeping your client involved throughout the entire project allows them to see the product as it develops and give feedback. This ensures that the client is getting exactly what they asked for.

Four Topics in Software Product Management

Process

A process organizes the work of people into distinct high-level phases or stages to develop a software product. Example phases are:

• Specification
• Design and Implementation
• Verification and Validation

Specification activities discover and define what the software is expected to do. Design and implementation activities structure and construct the software solution. Verification and validation activities test for potential defects and review whether the product meets the client’s needs.

Requirements

Good development processes help you to develop a product efficiently, but that’s only half the story. Every project needs requirements to define the product to be built. How you well define those requirements often dictate whether the project is a success. Therefore, it’s important to get requirements right.

In software, requirements are a set of specific descriptions to help capture your client’s needs. Requirements can be mapped to features of the software product. When combined, processes and requirements are the backbone of any successful software project.

Clear requirements are important. Ambiguous requirements can create confusion among the development team and with the client. Avoiding confusion** is an important part of the software product manager’s role. There are techniques to properly elicit and express requirements. By spending the time to refine requirements, you can also detect potential errors in your product before it’s even built. By clarifying ideas, development becomes focused and efficient.

Every project comes with a set of requirements, whether you clarify and track them or not. In the Client Needs and Software Requirements course, we will cover proven techniques for eliciting and expressing requirements. This will help you to maximize the effectiveness of your requirements.

Planning

Planning involves organizing tasks and schedules to align software development activities with requirements, in order to make timely progress through the phases of the development process. Creating tasks and schedules requires identifying who should do the work, and estimating how long that work will take. Planning includes:

• Breaking down work into tasks
• Estimating time for tasks
• Assigning work
• Risk management
• Contingency plans

Planning is not just for the beginning of the project. In software development, planning is something that occurs constantly throughout the project. Software is always evolving. Your plans have to be flexible! When you have a process to review your plan, your project becomes more agile. Meaning, you can easily adapt to change.

Time Estimation

Poorly written requirements make accurate time estimates difficult. The more specific the requirements are, the clearer it is to estimate how long the work will take to complete!

Assigning Work

The developers and the software product manager determine the time estimates for tasks in software development. The developers know best how long it takes them to develop features, but as a software product manager, you also have a sense for timelines based on your own experience.

Risk Management

If you can identify future risks and do something in the present to mitigate them, then your project will have a higher chance of success.

Risk management entails developing contingency plans to address risk. What are some examples of things that could go wrong?

• What if a developer gets sick?
• What if someone quits?
• What if your client contact changes?
• What if your technology crashes?

Through risk planning or risk management you can anticipate problems that may occur and formulate contingency plans in the event the risks become real.

Monitoring

When things change in the project (and they will change), it’s important to have an idea of what’s going on in the project, so that you can deal with these changes as effectively as possible. Monitoring also helps to make sure you’re on track to meet your goals. If you’re not, monitoring also helps you to find out why, and what you can do to fix it. In essence, monitoring your progress helps you to stay afloat over the lifetime of the project.

If the client asks for more features, a manager effectively monitoring the project can easily gauge whether their team has available resources, allowing them to adapt to changes within the project for a much higher likelihood of success. This moves you from being a reactive software product manager to a proactive software product manager.

Transparency is another aspect of monitoring. Transparency means that everyone on the team knows the status of the project, not just “management.” The development team and the product manager work together to monitor their progress with a positive, goal-driven, and team-based mentality.

Many tools and techniques exist to help you monitor, analyze, and review your progress. We will cover a subset of these tools and techniques in the Reviews and Metrics for Software Improvements course.

Software Processes and Agile Practices

Introduction to Processes

Processes and Practices

The Importance of a Process

Establishing a process is a key starting point for every software development project. A process organizes the work on a software product into distinct phases. In general, the work that is undertaken for a project will transition from one phase to the next. Each phase has specific activities and tasks that must be performed. By creating distinct phases with clear steps and deliverables, the use of processes structures the software development in a manner that provides clarity for everyone involved.

Software development requires continuous evaluation and decision making while moving through each phase of a given project. This continues well past the initial development project. A software product can have a long life cycle involving multiple versions with improved features and resolved defects.

Life Cycles and Sub-Processes

A software life cycle process refers to a process that covers the entire spectrum of software development, from the product’s initial conception to its eventual retirement. A life cycle process is an all-encompassing approach to software development, which may include sub-processes for major releases and product evolution. Of particular interest for this course is building a new product, which requires a process that organizes how to get the product from an idea in the client’s mind to working software that an end-user experiences. The software life cycle processes presented in this course will focus on this software development problem.

Processes and Phases

As noted before, a process is divided into multiple phases. For example, the phases of a process to create a software product may be:

• Specification
• Design and Implementation
• Verification and Validation

Phases—or milestones—within a process need only be identified in a logical manner and organized so that the phases contribute to the completion of the process.

Phases, Activities, and Tasks

For example, consider the Verification and Validation phase identified previously; one of the activities within might be Executing Tests Tasks related to the activity of executing tests could include:

• Writing test framework code
• Designing tests
• Writing tests
• Running tests

Tasks are where the real work gets done, no matter what process is used. Tasks are the small, manageable units of work for the project. They are the building blocks for completing an activity, finishing a phase, and ultimately completing a process.

Last Word on Phases

Adopting and adapting a suitable process will be key in structuring the work for a successful project. Designing a process can start from scratch or may be based on one of the many process models that have already been used successfully. A variety of process models will be presented during this course.

Every process model will have phases; however, there are major differences between models in terms of what activities constitute their phases and the sequencing of the phases. Three types of process models are:

• Linear process models – phases that happen sequentially, one after another
• Iterative process models – phases that are repeated in cycles
• Parallel process models – activities that occur concurrently

Tasks and Task Dependencies

As introduced above, tasks are the most basic unit of work that will be managed. Tasks in software development include small pieces of work, such as:

• Write source code for a feature
• Design a feature
• Write documentation
• Install a library
• Test a feature

Tasks often have dependencies—for example, a task that must wait for another task to complete is said to be dependent on that other task. Dependencies will impose a specific order for tasks to be completed. It is important to understand and sequence dependent tasks appropriately.

For example, imagine a process that has been divided into three phases:

1. Specification
2. Design and Implementation
3. Verification and Validation

An activity within the second phase might be “designing user interfaces.” Tasks within this activity would be ordered to reflect any identified dependencies. One task is to design the user interface look. Another task is to design the user interface behaviour, which depends on having the look established.

Although this is a small example, it does illustrate the need to identify all task dependencies, to avoid doing tasks out of order and wasting resources.

Tasks and Roles

Ultimately, it is specific people who perform the tasks. However when assigning tasks, it is good practice to assign them to roles rather than a specific person (e.g., Sam) or even a specific position (e.g., Software Engineer). There are very good reasons to approach assignment of tasks in this manner. First, even over a specific phase, people can change in an organization, so assigning tasks to roles is more constant over the life of the project. Second, setting tasks to roles will help avoid any perceived personal choices that can occur when assigning tasks to specific people instead of a given role.

A role is job-related activity assigned to a person. As mentioned above, a team member named Sam may have a job title “Software Engineer”; however, one of his roles is to program. Any given development team will have multiple members who can perform many roles, such as:

• Graphic designer
• Programmer
• Tester
• Project manager
• Product owner

Each role on a team describes specific skills that are needed to accomplish any given responsibility or task. For example, a programmer may write code for a certain feature and this might then be assigned to our example team member Sam, who is a Software Engineer. A tester will be assigned to test that feature, and this role may be filled by a Junior Developer named Theresa.

A role performs a task.

Tasks and Work Products

A work product is an output produced by completing a specific task. Work products, of course, do include the final product, but they also include other intermediate outputs such as design documentation, requirements documents, source code, test cases, and project management artifacts such as status reports and sign-off forms.

Since work products are outputs of tasks, we can say that a task produces a work product. Work Products as Outputs and Inputs

As mentioned, some tasks depend on other tasks. So, the work product output of an earlier task will also be the input for a subsequent task. For example, the output of a task to design a feature becomes the input for a task to write the source code for that feature.

Not only does a task produce work products as output, it also uses work products from another task as input.

Tasks and Resources

Completing any given task requires resources to advance or fund it, such as time, people, technology, knowledge, and money.

A task consumes resources.

Practices

Practices are strategies used to execute processes smoothly. Practices contribute to the effectiveness of a development process. For instance, a manager can follow proven management practices for: scheduling and organizing tasks, minimizing resource waste, and tracking completed work. Additionally, estimating tasks, holding daily meetings, improving communication, and doing periodic reviews of the project are all practices that can help a process run well. A developer can follow established development practices for: preparing effective tests, maintaining simplicity, and conducting technical reviews. This ensures a quality product with low defects.

Practices are often gathered into a methodology. Put another way, a methodology is a set of practices. Methodologies based on the philosophy outlined in the Agile Manifesto are known as Agile methodologies. Scrum is an example of an Agile methodology. It is an iterative and incremental software development methodology for managing product development. All the practices associated with Scrum adhere to Agile principles and philosophy.

The Agile Manifesto provides the philosophy, and an Agile methodology provides a set of day-to-day practices that align with that philosophy.

Practices and Process

Certain practices lend themselves to particular phases in a process. For example, within the Specification phase of a software life cycle process, practices designed to help elicit needs and express requirements are useful.

Other practices are useful throughout the entire process, such as those that pertain to project management, such as having daily meetings, monitoring how productive the team accomplishes work, and keeping everyone aware of outstanding items that still need to be completed. Specific practices will be examined later in this course as Agile methodologies are presented.

Adopting good practices reduces wasted resources. Effective planning and communication prevents duplicating work or producing a feature that is not needed. Good practices then help to keep the project on schedule and on budget.

Processes and practices are flexible and customizable. Combine various aspects of processes and practices to create something customized to your development needs. Finally, be open to making adjustments that refine the processes and practices to best fit your project and product.

Software Engineering Activities

A process is made up of phases. A phase is made up of activities. An activity is made up of tasks.

We have already identified that tasks produce work products that can become the inputs to other tasks. Since related tasks comprise an activity, an activity too has work product inputs and outputs (i.e., the

Software Processes and Agile Practices | 9 As the software engineering activities are discussed, they will be grouped into generalized phases to give concrete examples of how the activities can belong to the phases of a process.

initial input(s) into the related tasks and the final output(s) upon the completion of those tasks). Additionally, just as tasks have dependencies, so too do activities. For example, the activity of “creating tests” will result in a work product output that will enable the next activity of “executing tests” to begin.

Specification Activities

A specification phase is often a starting point for developing a software product. These activities focus on the requirements for the product. In a linear process model, specification activities might happen once at the beginning of the process; however, in iterative or parallel models, specification activities can be revisited multiple times to capture updated client needs and suggested product improvements. A software product manager plays a significant role in specification activities.

Specification activities usually include:

• Identifying ideas or needs
• Eliciting requirements
• Expressing requirements
• Prioritizing requirements
• Analyzing requirements
• Managing requirements
• Formulating potential approaches

The importance of identifying ideas or needs should not be underestimated. While it may seem self- evident, thoroughly understanding or exploring the idea or need that drives development will help to create a great software product.

Once the core idea of the product is understood, the next steps are to define the requirements.

1. Elicit requirements (probe for them)
2. Express requirements (write them down in a structured way)
3. Prioritize requirements (rank them by importance)
4. Analyze requirements (check them for clarity, consistency, completeness))
5. Manage requirements (organize, reuse, reference them )

Software engineering activities place an emphasis on having a good initial set of requirements to guide development work. The Client Needs and Software Requirements course within this specialization is devoted to the activities and practices to form effective requirements.

The final activity, formulating potential approaches, allows the product team to outline a strategy, consider alternatives, and further refine their next steps.

Design and Implementation Activities

These are activities accomplished by the development team to design and implement the software product. Managers need to track and monitor the work products that result from these activities.

Design and implementation activities can include:

• Designing the architecture
• Designing the database
• Designing interfaces
• Creating executable code
• Integrating functionality
• Documenting

These are all activities that happen before any programming can begin. Having a design for the software architecture, related databases, and interfaces will improve the ability of developers to work together towards a common goal. Once programming begins, programmers should be integrating or combining their code at regular intervals to ensure compatible functionality. Internal documentation will help new developers when they join the team or enable existing team members to work on development of unfamiliar aspects of the product.

Verification and Validation Activities

Constant verification and validation of the product will ensure that its development is on the right track.

Verification and validation activities include:

• Developing test procedures
• Creating tests
• Executing tests
• Reporting evaluation results
• Conducting reviews and audits
• Demonstrating to clients
• Conducting retrospectives

Verification typically consists of internal testing and technical review activities that ensure that the product does what it is intended to do, according to the documented design and requirements.

Validation activities such as demonstrating to clients help to check that the product meets the needs of the client and/or the end users. With iterative or parallel process models, feedback at this stage can be incorporated into new specifications to improve the product through the next cycle of development.

Both the product and the process can also be improved. Conducting retrospectives is an activity to identify areas to do better next time. Retrospective exercises with the development team will generate ideas for improving the process and the product.

Project Management Activities

Although the example phases represent a natural flow through software development, there are also ongoing project management activities that generally occur in parallel to the activities discussed above.

Project management activities usually include:

• Creating a process
• Setting standards
• Managing risks
• Performing estimations
• Allocating resources
• Making measurements
• Improving the process

Creating a process is an important part of managing a project because it sets the initial phases for development. A process provides a structure of expected activities and work, which help to guide a team through a product development project.

Along with a process, setting standards is needed to ensure the team’s activities are performed consistently. The team needs a clear set of expectations on aspects of development like coding conventions, documentation levels, testing strategies, and when work should be considered done. A development team may set a standard that work for a feature is considered done, for example, when the implemented source code follows a specified convention, when the documentation has been provided to the developers and end-users, or when features has been tested.

Another project management activity is managing risks. This requires constant analysis and mitigation of potential risks (e.g., business, technical, managerial, scheduling, and security risks). Inputs for managing risks may require historical project records, project estimates, the software’s detailed design, and the life cycle process. Any part of the project that may be considered vulnerable to failure would be an input work product for managing risks. The output work product is a risk plan that outlines potential risks and mitigation strategies. Ongoing risk review will identify and mitigate new risks that may emerge throughout the development process.

Furthermore, effective project management relies on performing estimations. Estimation is a critical activity in software development since development timelines are based on estimates of how long it takes to complete tasks. When estimates are too inaccurate, a schedule can be severely compromised. Tasks involved in the estimation activity include collecting data for estimates, performing estimate calculations, and evaluating estimates. For example, performing an estimate for the duration of a given task is itself a task with an input work product of collected, historical, task-duration measurements. The output work product is the estimated duration itself, which can be used in subsequent scheduling tasks.

The activity for allocating resources ensures that people, time, money, and equipment are deployed to do a required task. Assigning tasks and creating a work schedule are both tasks with the resource allocation activity.

Making measurements is another important project management activity. This involves tasks like defining usable metrics, calculating data, and analyzing metric data. Metrics are used to track and assess the quality of the product and/or the process.

Improving the process is a critical part of effective project management. It is important to recognize that, like the product, improvements can also be made to the development process. It is as important to test and review the process, as it is to test and review the product. Measurements are useful inputs for calculations to determine how the process can be improved.

Summary of Software Engineering Activities

Outlining these software engineering activities provides an idea of how they contribute toward developing a software product or managing a software project.

Process Models

Module Overview

Not all process models fit all project needs. It is worthwhile to gain a perspective of the relative strengths and weaknesses of each model, in order to ensure that you are musing the best tool for the job. A project may find that some process models are more complex or comprehensive than needed.

Linear Models

Linear process models follow a series of phases, one by one, with no return to prior phases. The product is essentially specified, designed, developed, and released in that order, with no opportunity to revisit earlier phases. Linear processes are best suited to projects where very little feedback or refinement is expected. Successful projects following a linear process model are well understood from the start, with little to no room for change.

In the early days of computing, the process of software development did not favour quick experimentation. Computers were not as prolific as they are now, and developing for them was much costlier. Computer code had to be written (or punched into cards) with meticulous attention to detail, and the time it took to compile the code was often significant and expensive. As a result, there was more emphasis on detailed, upfront design. Linear process models fit into this early way of thinking.

Waterfall Model

The Waterfall model is a linear process model, in which each phase produces an approved work product that is then used by the next phase. The work product flows into the next phase, and this continues until the end of the process, like a waterfall. There are modified variants of the Waterfall model that allow flows to prior phases, but the dominant flow is still forward and linear.

Based on the waterfall process shown, at the end of the requirements* phase, there is an output work product: a requirements document. This document is formally approved and then fed into the next phase: design. This passing of work continues from phase to phase until the software product is the final output.

Benefits and Drawbacks

It may be primitive, but the Waterfall model does have benefits - even in today’s development projects: This process is easy to understand; It clearly defines deliverables and milestones; It emphasizes the importance of analysis before design, and design before implementation; and it can be adopted within teams using more sophisticated processes, for well-specified parts of the product that can be outsourced.

The Waterfall model faces one major flaw: It is not very adaptable to change. That is, it is not amenable to Agile principles. Modern software development is often very dynamic; flexibility with respect to changing needs and emerging technologies is valued. The Waterfall model focuses on knowing all the requirements up front. It is simply not designed to address mid-stream changes easily or without great cost, because it would require revisiting earlier phases. In addition, testing occurs late in the process, and defects found late tend to be more difficult and costly to fix.

Under the Waterfall model, the client does not see the product until close to the end of development, and so the developed product may not match what the client had envisioned.

V-Model

The V-model is another linear process model. It was created in response to what was identified as a problem of the Waterfall model; that is, it adds a more complete focus on testing the product. The distinguishing feature—and namesake—of the V-model are the two branches that turn a linear structure into a “V” shape. Like the Waterfall model, the V-model begins with analysis and the identification of requirements, which feeds product information into the design and implementation phases. The analysis and design phases comprise the left branch of the V. The right branch represents integration and testing activities. As testing work proceeds up the right branch, some level of the product (on the right side) is actively verified against the corresponding design or requirements (on the left side).

Benefits and Drawbacks

The V-model has the same advantages and disadvantages as the Waterfall model in that it is straightforward to understand, but it does not accommodate change well. However, allowing the development team to verify the product at multiple levels in explicit phases is an improvement over the Waterfall model.

In both the Waterfall model and the V-model, the client does not see the finished product until everything is virtually complete. The next evolution in linear processes is devising a way to involve the client in the development process.

Sawtooth Model

The Sawtooth model is also a linear process model, but unlike the Waterfall and V models, the client is involved to review intermediate prototypes of the product during the process. As the process proceeds linearly, there are phases that involve the client in the top section of the diagram and phases that involve only the development team in the bottom section, which creates a jagged “sawtooth” pattern.

Benefits and Drawbacks

Having the client involved earlier in the process increases the likelihood that the product will meet the client’s needs; this is a definite advantage of the Sawtooth model compared the Waterfall model and the V-model. However, like them, the Sawtooth model is still a linear process, so there is a limit to incorporating anything more than incremental changes.

Last Word on Linear Process Models

The main thing linear process models have in common is their sequential organization of phases. Development happens in a simple and straightforward way. Not being able to revisit early stages such as analysis or design results in the inflexibility of these models. Decisions made early in the process will constrain the final product.

Early linear process models subscribe to a manufacturing view of a software product. In essences, this means that it is machined and assembled according to certain requirements. Once produced, the product would only require minor maintenance upkeep, like an appliance. The emphasis falls on getting all the requirements specified “correctly” at the beginning of the process and not changing them afterwards. In reality, developing a software product is more of a creative endeavour, which necessitates experimentation and constant rework.

Linear process models are a legacy from an era when computing power was relatively expensive compared to human labour. So, programming was efficient for computers, but not necessarily for people. The time elapsed between writing a line of code and seeing its result could be hours. Trying small programming experiments to quickly test out ideas were not practical. Linear process models fit into a mode of thinking—get things right the first time and avoid rework.

Like we said before, these linear models can still be useful for certain situations. For example, linear processes are great for developing simple, well-defined product. Indeed, more advanced process models still have certain phases that happen linearly.

Iterative Models

Iterative process models differ from linear process models in that they are designed for repeating stages of the process. That is, they are iterative or cyclical in structure.

The advantage of iterative processes is the ability to loop and revisit previous phases (and their activities) as part of the process. Each “loop back” is an iteration, hence the name “iterative process.” Iterations allow for client feedback to be incorporated within the process as being the norm, not the exception. Iterative process models are readily amenable to Agile practices, yet they also embody sequential portions reminiscent of linear process models.

Spiral Model

The Spiral model was introduced by Barry Boehm in 1986. The model outlined a basic process in which development teams could design and successfully implement a software system by revisiting phases of the process after they had been previously completed.

A simplified version of the Spiral model has four phases, which have associated goals: determine objectives, identify and resolve risks, develop and test, and plan the next iteration. Taken in order, the four phases represent one full iteration. Each subsequent iteration has the sequence of the four phases revisited, and each iteration results in a product prototype. This allows the development team to review their product with the client to gather feedback and improve the product. Early iterations lead to product ideas and concepts, while later iterations lead to working software prototypes. The Spiral model is commonly charted with the four phases appearing as quadrants, and an outward growing spiral to indicate progression through the phases.

Drawbacks of the Spiral Model

Estimating work can be more difficult, depending on the duration of the iteration cycle in the Spiral model. The longer the iteration cycle, the further into the future one needs to plan and estimate for; lengthy iterations can introduce more uncertainty in estimates. It is easier to estimate the effort on small things and plan for two weeks ahead than to estimate the effort needed on many big things for several weeks ahead.

Also, the Spiral model requires much analytical expertise to assess risks. These extensive risk-assessment tasks can consume a great deal of resources to be done properly. Not all organizations will have the years of experience, data, and technical expertise available for estimation and risk assessment.

Last Word on Spiral Model

This simplified description of the Spiral model introduced the idea of an iterative process. Work is done in iterations that allow for revisions of the product at certain specific intervals. The ability to harness a repetitive process to make further refinements to a product is a clear advantage over the earlier linear models.

Parallel Models

The Spiral model is a true iterative process for software development, which means that the product is built in a repeated series of phases and product refinements are introduced at specific phases within the cycle. Parallel processes use a similar style of iteration—products are built in iterations—however, parallel processes allow for more concurrency of activities and tasks.

Unified Process Model

Software Processes and Agile Practices | 20

The Unified Process model is an iterative model of software development. Its basic structure has sequential phases within a repeatable cycle. Within most of the Unified Process model’s phases, work happens in small iterations until the phase is deemed complete. Usually, phases are deemed complete when a milestone, a specific and identifiable point in a project,*** is reached.

Software Processes and Agile Practices |

While the general structure of the Unified Process is iterative, the model allows for tasks done in one phase to also occur in another. So, a requirements task or activity can happen throughout the phases instead of in just one. This also means that, for example, a requirements task, an architecture design task, and a test development task can happen in parallel with the same phase. To contrast this, in the Waterfall model, these tasks would be organized into specific, separate phases, with no parallelism for those tasks.

Phases within the Unified Process Model

The Unified Process model has four phases, with each phase having a distinct aim.

1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase

Inception phase

This first phase is meant to be short—enough time to establish a strong enough business case and financial reason to continue on to the next phases and make the product.

To do this, the inception phase** typically calls for the creation of basic use cases, which outline the main user interactions with the product. Also defined are the project’s scope and potential project risks. The inception phase is the only phase in Unified Process model that does not happen in iterations. If the inception phase is long, this might suggest wasted time over analyzing the requirements.

The completion of the inception phase is marked by a lifecycle objective milestone. The work product for achieving this milestone is a reasonable description of product viability and the readiness to move on to the next phase of the process.

Elaboration phase

The Unified Process focuses on the importance of refining the product’s architecture over time. Architecture is a set of designs upon which the software product is built. So, the goal of the elaboration phase is to create design models and prototypes of the product as well as to address risks. This phase is also the first of the phases to incorporate small iterations within the phase.

Besides defining the system architecture, developers refine the requirements conceived earlier in the inception phase. They also develop key requirements and architecture documentation, such as use case diagrams,** and high-level class diagrams. This phase gives the foundation on which actual development will be built.

Building a prototype will likely require several iterations before the requirements and architecture models are deemed complete enough to move on.

At the end of the elaboration phase, developers deliver a plan for development in the next phase. This plan basically builds on what was developed during the inception phase; it integrates everything learned during the elaboration phase so that construction can happen effectively.

Construction phase

Similar to the preceding phase, the construction phase has iterations and focuses on building upon the previous work so far. This is where the software product begins to take shape.

Since the Unified Process model is a parallel process, when the construction phase begins, elaboration phase work will still continue. The only difference is that the emphasis on the work may change.

Testing and programming activities may have been important in the elaboration phase (for technical feasibility studies or to set up the development environment), but they become even more important in the construction phase. Similarly, assessing risks is important in the inception phase, but it’s less important in the construction phase.

In the construction phase, full use cases are developed to drive product development. These improvements upon the basic versions developed in the inception phase consist of a set of possible sequential interactions between users and systems. They help to identify, clarify, and organize functionalities of a product. These use cases are more robust than the ones initiated in the inception phase, and offer more specific insights into how the product should support end-user tasks.

The product is built iteratively throughout the construction phase until it is ready to be released. At that point, the development team begins transitioning the product to the client and/or the end users.

Transition phase

During this phase the development team receives feedback from users. The transition phase reveals how well the product design measures up against users’ needs. By gathering user feedback, the development team can make improvements to the product, like bug fixes and developing future updates to be released.

Upon completing the transition phase, it is possible to cycle back through the phases of the Unified Process again. For example, there may be a need to create further releases of the product or to incorporate user feedback as a means of influencing the plans for later development.

Last Word on Unified Process Model

Unified Process model is an example of a parallel process that features iterations. Activities like requirements, design, and implementation can happen at the same time, and they all drive the product to a “release” stage. However, once the product is released, the process can begin another cycle to refine and improve the product.

Iterations also happen within phases; for example, the elaboration phase may lead to several iterations of design before the work product is ready for the construction phase.

The Unified Process is well suited to large projects where iterations can allow the product to grow naturally beyond the original inception for the product.

You may notice a pattern of evolving ever-more advanced processes, but this does not mean that simpler processes are outdated! While earlier linear and iterative processes may be less sophisticated than modern parallel processes, the older processes are still frequently used in simpler situations.

Prototypes

Developing software products through a series of intermediate prototypes was a theme in both the Spiral and Unified Process models. Let’s explore prototyping in more detail.

There are five types of prototypes:

1. Illustrative
2. Exploratory
3. Throwaway
4. Incremental
5. Evolutionary

Illustrative prototype

This is the most basic of all prototypes. They could be drawings on a napkin, a set of slideshow slides, or even a couple index cards with components drawn out. The essence of an illustrative prototype is to get a basic idea down.

Illustrative prototypes can give the development team a common idea off of which to base their work, or to help them get a system’s “look and feel” right

without investing much time or money into developing a DID YOU KNOW?

product. Use illustrative prototypes to weed out

problematic ideas or as a guide for later development. Some prototypes go as far as “faking” their

functionality by having a human control Illustrative prototyping can involve storyboarding, or some of the functionality of the system

wireframes. They are all meant to show how a system will behind the scenes.

work or illustrate a concept using only diagrams and

pictures.

Exploratory Prototype

Exploratory prototyping puts the focus on more than just the product’s look and feel. By building working code, the development team can explore what is feasible—fully expecting to throw the work out after learning from the prototype. With more time, a more comprehensive look at what the product will look like can emerge, as well as an understanding of the effort needed to build that product.

Exploratory prototyping is expensive in terms of consuming resources, but it is used because it is better and less costly than finding out later in the process that a product solution just cannot work. The usual motivation behind exploratory prototyping is that the product developers want to study the feasibility of a product idea. Unlike illustrative prototyping, which is only concerned with what the product looks like, exploratory prototyping is about how realizable it is to develop the product or how useful the product may be, before committing further effort to the idea.

Throwaway Prototype

The first version of almost any product is bound to have various problems. So, why not just build a second, better, version from scratch and toss away the first? These first versions of products are known as throwaway prototypes – you build a functioning product that will get tossed out.

Throwaway prototypes allow the opportunity to learn from past mistakes. There could be many useful lessons and problems revealed in the first version that can be avoided in a second version. This affords the chance to build the software product on a more robust second-generation architecture, rather than a first-generation system with patches and fixes.

**DID YOU KNOW? **

A common feature of illustrated, exploratory, and throwaway prototypes is that none of the effort to build the prototypes will end up in the final version of the product. Lessons are learned from the effort, but the development resources put into building the prototype are essentially lost.

The final two types of prototypes will demonstrate how development effort in building a prototype can contribute to the final product. The key is to have working software for each successive prototype, any of which could be released as a version of your software product.

Incremental Prototype

When a product is built and released in increments, it is an incremental prototype. Incremental prototyping works in stages, based on a triage system. “Triaging” means assessing each of the system’s components and assigning a priority. Based on that priority, a product’s components are built iteratively in increments from “most important” to “least important.” In this way, incremental prototypes make use of the process philosophies behind iterative processes models.

Priorities for a software product’s features are based on three categories: “must do,” “should do,” and what “could do.” Core features are assigned the highest priority—must do. All the non-critical supporting features are “should do” items. Remaining extraneous features are the lowest priority— could do.

Based on these priorities, the initial iterations of incremental development focus on delivering “must do” priorities. The resulting software product with the core features could be released as a complete first-generation incremental prototype.

As resources permit, features under the “should do” priority can be developed for a similar second- generation incremental release, followed by a third release with features from the “could do” category. The end result of these iterations is a series of incremental prototypes from essential basic features to fully featured.

Evolutionary Prototype

The final type of prototype is the evolutionary prototype. This prototype approach is very similar to incremental prototypes, but the difference is found in the first-generation prototype. In evolutionary prototyping, the first-generation prototype has all the features of the product, even though some features may need to “evolve” or be refined. A comparable first-generation incremental prototype has only a basic set of core features.

Both incremental and evolutionary prototyping are ways to make working software that can be shown at regular intervals to gain further feedback. In practice, both approaches can be blended. A major benefit is the morale boost for the development team as they see the working product early and are able to contribute improvements over time.

Last Word on Prototypes

Given the different types of processes, think about how prototyping might fit into the Spiral model and Unified Process model.

In the Spiral model, a first iteration may be the creation of an illustrative prototype. This could be accomplished with a few drawings on paper to sketch an idea of how the system will work. The same illustrative prototype could work for the inception phase of the Unified Process. Prototypes help to better visualize what the product does and therefore make feature decisions based on what the product might look like.

Subsequent iterations could build on the illustrative prototype with either an incremental or an evolutionary prototype approach. Using the first iteration—an idea sketched-out on a few pieces of paper—further testing of the idea, outlining some key features, and the next prototype will take shape. Before long, a prototype is ready that can be taken to a client or potential investors to prove that the product is conceptually viable.

The core idea behind all prototyping is to gain feedback on versions of the product, in order to make informed decisions about the product’s future.

Continuous Delivery

In incremental or evolutionary prototyping, the product gets added to or refined iteratively over time. The idea is to start with a basic product. Over time, successive prototypes are constructed. Typically, these prototypes are delivered to the client for feedback. However, this notion of delivery may be ad hoc and labour intensive. For example, it might take a great deal of manual work for developers to build and integrate the code into a runnable prototype. This prototype may only run on the developer’s environment, on their specific device, rather than as a product suitable to deliver to the client.

Continuous Delivery applies automation so that intermediate releases of working software can be more disciplined and frequent. This allows developers to more easily deliver versions of a product continuously as it is constructed. The aim is to have working software that is tested, ready to run, and releasable to others. For example, whenever a developer commits a code change, it will be automatically built, integrated, tested, released, and deployed. Ideally, the time from making a product change to having it tried by an end user can be short and frequent. Problems arising in any of these automated steps can be noticed earlier, rather than later.

Versions that are not ready are not forced to be released. Typically, releases of prototypes are placed in specific channels. For example, there can be a “developer” channel for the day-to-day releases that developers generate, a “test” channel for a wider group internal to a company, or a “stable” channel for releases that are more “proven.” Different expectations of feedback and tolerances to issues could occur on each channel.

The Continuous Delivery practice fits well with iterative process models like the Unified Process. The most relevant phase in Unified is the construction phase, where multiple short iterations build the functionality of the product through a series of prototypes that are continuously delivered.

Within any of these iterations, the development team would work on a number of tasks to construct the next prototype for release, including detailed design, writing code, and making test cases. Determining which features are the focus for each iteration could be guided by a prototyping approach that is incremental, evolutionary, or both.

In the Unified Process, the architecture or high-level design of the product would be mostly modeled in the elaboration phase. Detailed design defines models that describe specific lower-level units, relations, and behaviours in the product. Ultimately, developers take these models, make decisions on algorithms and data structures to write or generate the code, and prepare corresponding test cases.

To support Continuous Delivery, automated tools are used to build and integrate the code, run low-level tests, package the product into a releasable form, and install or deploy it to a test environment. For example, building the code might require other dependent code to be rebuilt. To be fast, especially for large software products, the build automation has to be smart enough to only rebuild what’s really necessary.

As code is written, features start to take form within the product. Continuous Delivery ensures there is a releasable prototype ready for end users and clients to try by the end of the iteration.

Should the project be abandoned, there would in theory still be a releasable product, even if incomplete.

Product quality would also improve. Through the iterations, the product is checked in small, frequent doses, rather than all at once.

Microsoft Daily Build

For the Microsoft Daily Build, each “iteration” of the construction phase is laid out in a day, hence the “daily build.”

The point of the Microsoft Daily Build is to ensure that the programmers are all in sync at the beginning of each build activity. By following a process that makes the developers integrate their code into the larger system at the end of every day, incompatibilities are detected sooner rather than later.

To control this, Microsoft uses a system of continuous integration. When a developer writes a piece of code and wants to share that code remotely with anyone else on the team, the code must first be put through an automatic testing process, which ensures that it will work with the project as a whole.

All the developers can easily see how their work fits into the product as a whole, and how their work affects other members of the team.

Continuous integration not only keeps developer morale up, but it also increases the quality of the product. The daily build does this by giving developers the ability to catch errors quickly before they become a real problem. A successful build allows overnight testing to proceed, with test results reported in the morning. At Microsoft, as an incentive for successful daily builds, a developer whose code breaks the build must monitor the build process until the next developer to break the build comes along.

Last Word on Continuous Delivery

Continuous delivery can be incorporated into an iterative process like the Unified Process to release incremental or evolutionary prototypes.

Combinations of approaches, like the Unified Process with prototyping and Continuous delivery, can create powerful tools for projects where regular feedback is valuable, product quality is important, and issues need to be caught early. This combination approach is a significantly more robust process than linear processes, for example, but it may not fit every situation. There will be circumstances, especially on small, short-term projects, where setting up the required infrastructure for such a process would take more time than it is worth.

Smaller projects may benefit from more simple linear processes, such as the Waterfall, V, or Sawtooth models. However, linear processes are too simplistic for very large projects.

Process as a Tool: Choose the Right Tool for the Job!

Keep an open mind when selecting a process to fit your project. It is a mistake to think that iterative or parallel software process models are always the best tools for the job. Depending on the situation, a different process could be more effective. Also, aspects of different processes can be combined to better suit the needs of the project. Do what works best for your projects!

Agile Practices

• understand how linear, iterative, and parallel processes work with Agile principles.
• describe the 12 principles of Extreme Programming (XP), and how they fit within Agile methods.
• recognize what types of projects will work best with Extreme Programming (XP), and which ones will not.
• understand the role of a system metaphor.
• describe the difference between an acceptance test and a unit test.
• understand the goals of paired programming.
• describe the Scrum practices: sprints, product backlog, sprint review, Scrum product owner, Scrum master, and Scrum development team.
• describe how Scrum focuses on management.
• understand the process for establishing and maintaining the product backlog, and who is responsible for defining, prioritizing, and changing requirements.

Before continuing please be clear about with the terms that have already been covered.

Software processes structure software development work into phases. For example, the Unified Process model is an iterative process that organizes the timeline for a product into cycles of phases, where each phase typically has iterations. A process describes the expected outcomes from the activities done in the phases, so it establishes “what” needs to be done. For example, use cases are initially outlined within the inception phase of the Unified Process. Software practices are techniques for “how” to develop software products or manage software projects effectively. For example, early in a process, there are practices for how to prioritize the product requirements. Software methodologies are defined groups of practices.

Using Agile with Process Models

Given the process models to organize work in software development, how can Agile principles apply?

One Agile principle refers to early and continuous delivery, so that there is enough opportunity for close collaboration and feedback to improve the product. The Waterfall and V models only truly delivers to the client at the end of the development process, which is not early integration. As well, comprehensive documentation is not a major focus in Agile development, but the Waterfall and V models relies heavily on documentation and approving it when moving between phases. The culture of contracts and sign- offs is also not Agile. While the Sawtooth model does provide a couple of prototypes to the client during the process, it is not enough. So, the described linear process models do not work well with Agile principles and practices.

Iterative process models work much better with Agile practices because they allow for reflection and improvement. Iterative models also allow frequent and continuous releases to gather feedback. These releases are then refined and improved in the next iteration. Short iterations and small releases are aspects of Agile. So, the Spiral model with shorter iterations and Unified Process model with its iterations within phases would work well with Agile principles and practices.

Agile Practices

Practices are techniques, guidelines, or rules that help to develop the software product or to manage the software project.

Practices based upon the Manifesto for Agile Software Development are called Agile practices. Agile practices align with the Agile Manifesto. For example, the Agile development practice of having small releases fits with the Agile principle of delivering working software frequently. The Agile management practice of arranging a review meeting at the end of each iteration with the client fits with the Agile principle of satisfying the customer through early and continuous delivery of valuable software.

Practices are organized into methodologies. Methodologies consisting of Agile practices are called Agile methodologies. The remaining of this course will examine three popular methodologies, Extreme Programming, Scrum, and Lean, as well as a management practice called Kanban that works well with these methodologies.

Scrum

Scrum is an Agile methodology consisting of lightweight management practices that have relatively little overhead. Its practices are simple to understand but very difficult to master in their entirety. Scrum uses an approach that is both iterative and incremental. There are frequent assessments of the project, which enhances predictability and mitigates risk.

Three Pillars of Scrum

Scrum is based on three pillars:

• Transparency
• Inspection
• Adaptation

With transparency, everyone can see every part of the project, from inside the team and outside the team. Scrum encourages frequent inspection of work products and progress to detect undesirable deviations from expectations. The inspections, however, do not happen so frequently to impede development. Ken Schwaber, a Scrum trainer and author, says “Scrum is like a mother-in-law, it points out all your flaws.” Developers sometimes are hesitant to adopt scrum because it points out everything they are not doing right. When a deviation is detected, the team must adapt and adjust to correct the problem. Important is agreeing on standards for the project such common terminology and definitions such as the meaning of “done.”

Sprints and Scrum Events

The project timeline consists of a sequence of consecutive sprints. A sprint is an iteration, whereby an increment of working software is delivered to the client at the end. Each sprint is “time-boxed” to a consistent and fixed duration. That fixed duration is chosen at the start of the project, and is typically one or two weeks.

To enable the three pillars, Scrum outlines four required techniques or events that happen within a sprint:

• Sprint planning (to set expectations for the sprint)
• Daily scrums (to ensure work is aligned with these expectations)
• Sprint review (to gain feedback on completed work)
• Sprint retrospective (to identify what to do better in the future)

Sprint planning occurs at the beginning of a sprint to determine what will be completed in that sprint. This planning sets a sprint goal, a high-level view of what will be done. The plan also identifies the particular requirements to complete and the associated developer tasks.

To keep the team focused on the plan, daily scrums are brief meetings held early each day, when each team member outlines what they did previously, what they will work on, and what may be blocking their progress. To encourage brevity and avoid long meetings, the daily scrums are conducted with the team standing up. So, the daily scrum is also known as the daily stand-up meeting.

A sprint review happens at the end of a sprint to show the working software to the client and gain feedback. A sprint retrospective gives an opportunity to reveal lessons learned that can be addressed to improve future work.

Once sprint planning is done, work proceeds according to the sprint goal, determined requirements, and identified tasks. To avoid disturbing work in progress during the sprint, major new requirements changes are noted for later.

Scrum Roles

Scrum defines some key roles for a scrum team. Besides software developers, there is a product owner and a scrum master.

The product owner is the one person who is responsible for the product. All product requirements for the developers must come through this role. The list of requirements for the product is gathered in a product backlog, which the product owner is responsible for. The product owner also determines the priorities of these requirements and ensures the requirements are clearly defined.

The scrum master makes sure the scrum team adheres to scrum practices, by assisting the product owner and the development team. For the product owner, this help includes suggesting techniques to manage the product backlog, to attain clear requirements, and to prioritize for maximum value. For the development team members, this help includes coaching the team to self-organize and remove roadblocks. The scrum master also facilitates the four events listed above within a sprint.

Depending on the situation, there are various mappings for a client and software product manager to these roles. In a large organization or a large product, the client, software product manager, product owner, and scrum master can be all different people. In a small start-up company, there may be significant overlap.

Naturally, the client could be the product owner, who determines the requirements and accepts the completed work. However, with clients inexperienced with defining clear requirements for developers, a software product manager may represent the client and take on the product owner role instead. If there is not an actual client, as in a mass-market product, then the software product manager may represent the end users, and serve in the product owner role.

A team lead could be the scrum master to facilitate scrum practices by the team. In a small company, a software product manager with leadership qualities may need to take on the scrum master role. In any case of involvement, it is important for software product managers to understand the scrum roles and their responsibilities.

Scrum Development Team

The developers on a scrum team, also known as the scrum development team, must be self-organizing. No one outside the development team, not even the scrum master or product owner, tells them how to turn the backlog of requirements for a sprint into developer tasks to produce an increment of working software. Scrum development teams are small, ideally between three and nine people. They are self- contained, consisting of everyone and everything needed to complete the product. Also, each member generally takes on mixed tasks, like doing both coding and testing, rather than having dedicated coders and testers. There are no special sub-teams. Everyone on the team is responsible for the team’s work products. Accountability rests with the entire team.

Definition of “Done”

An important definition in scrum is the meaning of being “done.” The whole scrum team must agree to that definition. Typically, a requirement for a feature is considered done when it is coded, tested, documented, and accepted. A sprint aims to get the expected requirements to be truly done, or “done done,” rather than having the required features in half-done states or delivering software that does not work. To get a requirement done requires communication, integration, and synchronization by the team members. Half-done work might arise when a member works independently on something just to be busy, rather than helping to bring closure to each requirement. This may mean sometimes going slow to ensure that each requirement is truly done.

Extreme Programming (XP)

Practices

Extreme Programming (XP) is an Agile methodology consisting of effective development practices to achieve client satisfaction. The practices focus on constantly delivering software, responding to change, effective teamwork, and self-organization. These practices follow the principles outlined in the Agile Manifesto. Besides encouraging simplicity, communication, and feedback, XP fosters respect and courage.

Everyone is valued and respected for what they individually bring to the project, be that business experience, domain expertise, or development skills. Everyone is considered equal, so that the client, software product manager, and development team members are all on the same level, working together.

As for courage, the following quote is very fitting.

We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes whenever they happen.

• Extreme Programming, 1999

To apply XP, there are 12 practices to follow. The practices work together, so following all of the practices gives the greatest benefit.

Practice 1: The Planning Game

The client and development team work together in planning the product. This entails a larger planning session at project initiation and smaller sessions at each iteration. The larger session determines the product’s required features, their priorities, and when they should be released over time. A smaller session focuses on the features to be completed in an iteration and determines the development tasks needed.

Practice 2: Small Releases

Releases must occur as frequent as possible to gain plenty of feedback, which is best achieved if releases are small in terms of required new functionality. The required features should be prioritized to deliver value to the client early. The client and development team need to strike the right balance between what the client wants completed first and what can be developed early. Smaller releases also allow estimates to be more certain; it is easier to look a week or two ahead, rather than months. So, in the extreme, keep the iterations very short.

Practice 3: System Metaphor

A system metaphor makes it easier to explain the product to someone else; it can be an analogy to describe the product to someone who is not technical. For example, the desktop metaphor in graphical user interfaces helps to explain computer interactions in terms of something more familiar in the real world. Another example is the shopping cart metaphor in online shopping, which builds upon a concept from real-world shopping. A metaphor can also describe the product implementation to someone more technical. For example, the pipes and filters metaphor for software architecture helps to explain how a product implementation is structured around connecting and driving computing elements with information flows.

Practice 4: Simple Design

Focus on the simplest design that works to satisfy the client’s needs. Requirements change, so it would be wasteful in making elaborate designs for something that will change. Design what is needed to make the required features work. Do not over-engineer the design for a future that may not come. So, in the extreme, make the simplest thing that works.

Practice 5: Continuous Testing

In XP, tests are prepared for a required feature or functionality before its corresponding source code is written. This focuses efforts first on understanding what is required, making the user or programmatic interface to it simple, and preparing suitable tests to verify that the required behaviour has been achieved. If the test was difficult to write, it is a sign to rework the interface or original requirement. The implementation of the required feature or functionality comes afterwards. This practice is referred to as Test-Driven Development or TDD. Automating the tests will allow them to be executed continuously. So, in the extreme, write tests first and run them all the time.

There are two main types of tests involved: acceptance tests and unit tests. An acceptance test is for the client to verify whether a product feature or requirement works as specified and thus acceptable. An acceptance test typically involves something an end user does, touching a large part of the product. Such a test can be automated or can be a set of instructions and expected results that a human follows. A unit test is written and run by developers to verify whether low-level functionality works correctly. A unit test is typically specific, like testing an algorithm or data structure in some module of the software implementation.

Consider a social media application with a required feature that an end user can post a message. An acceptance test for this feature would involve actions that end users do, like initiating a post, entering a message, and submitting the post. The test would check that the actions basically work for some trial data. Underlying this feature, and the product in general, is low-level functionality to store posts. Unit tests would more thoroughly check that this functionality works, such as dealing with international characters or very long texts.

Practice 6: Refactoring

Refactoring is a practice to restructure the internal design of the code without changing its behaviour. The aim is to improve the design in small steps, as needed, to allow new product requirements to be added more easily, thus adapting to change. For example, refactoring could gradually reorganize the code to allow easier extension. A large, unwieldy module can be decomposed into smaller, more cohesive, more understandable pieces. Unnecessary code can be removed. As refactoring proceeds, the unit tests are run repeatedly to ensure that the behaviour of the code stays the same.

If refactoring is deferred or not done, then changes become more and more difficult. The undone work is like incurring an obligation, known as technical debt, to be “paid” in the future. A small amount may be fine to keep advancing the product, but a crisis could happen if a sufficiently large amount accumulates.

Practice 7: Pair Programming

To ensure high quality, XP employs pair programming, where two developers work side-by-side at one computer to work on a single task, like writing the code for a required feature. In regular code reviews, a developer writes some code, and after completion, another developer reviews it. Instead, in pair programming, the code is reviewed all the time by always having another pair of eyes to consider each edit. This brings together complementary skills and perspectives when solving a problem or generating alternatives. Riskier but more innovative ideas can be pursued, aided by the courage brought on by having a partner. Pairing a senior and junior developer can foster learning, where the senior one imparts strategic advice and the junior one offers a fresh perspective. In general, the pairs are not static but change dynamically. So, in the extreme, do code reviews all the time.

Practice 8: Collective Code Ownership

Although a specific pair of developers might initially implement a particular piece of the product, they do not “own” it. To encourage contributions, other team members can add to it or any other part of the product. Thus, the produced work is the result of the team, not individuals. So, project success and failure resides with the team, not on specific developers.

Practice 9: Continuous Integration

In XP, developers combine their code often to catch integration issues early. This should be at least once daily, but it can be much more frequent. With tests written first, the tests can also be run frequently to highlight pending work or unforeseen issues.

Practice 10: 40-Hour Work Week

XP aims to be programmer-friendly. It respects the developer’s balance of work and life. At crunch time, up to one week of overtime is allowed, but multiple weeks of overtime would be a sign of poor management or estimation.

Practice 11: On-Site Customer

The client is situated near the development team throughout the project to clarify and answer questions.

Practice 12: Coding Standards

All the developers agree to and follow a coding standard that specifies conventions on code style, formatting, and usage. This makes the code easier to read, and it encourages the practice of collective ownership.

Additional Management Ideas

Beyond the 12 basic practices, XP also suggests giving the team a dedicated, open work space, with people working together in person. Multiple computers are situated in the middle of the room, available for use by everyone. A meeting table and lots of wall space for whiteboards or sticky notes allows the team to collaborate and brainstorm.

The open work space allows people to move around. It encourages communication, propagates knowledge, and enables flexible work relationships, so everyone eventually learns how to work on all parts of the product, without a heavy focus on technical documentation.

A final management idea is to change XP itself. That is, fix XP when it breaks. While adopting all the basic practices is touted to maximize the benefits, not all the practices will work for every project or team. When a practice does not work, change it. Retrospective meetings are a way for the team to discuss what is working and what is not. Gather data to support what practices to adopt.

Drawbacks

One limitation is that XP is intended and suited for small development teams, for example, no more than ten people. As well, having a client available on-site with the development team may not be possible to arrange.

Also, XP does not offer practices to define the architectural design of the software. Instead, this design emerges in response to changing requirements and refactoring, using the system metaphor as a guide. This approach would produce working software early, but it might involve more rework than if some effort was spent to plan the architecture.

Pair programming is a major change to many developers. Some teams thrive in such a collaborative environment, while others do not. The practice requires respectful personalities that work well together. In reality, not everyone is compatible with everyone else.

Other Practices

• Understand that Agile practices are apt to change because technology changes and evolves.
• Explain Agile Practices other than Scrum and Extreme Programming, such as: Dynamic Systems Development Method, Feature-Driven Development, Behaviour-Driven Development, and Scrumban.
• Describe the differences between Unified Process and Agile Unified Process.
• Describe the practices of Lean, including: eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building quality in.
• Understand that “amplifying learning” is about seeking alternate solutions that vary in features, but is independent of technical aspects like programming languages.
• Understand what “seeing the whole” means.
• Setup a Kanban board, from identifying initial tasks to completing them.
• Explain what “done” means from a Kanban perspective.

Other Agile Methodologies

Software engineering methodologies have evolved over the years. While Scrum and Extreme Programming are very popular and widely used in industry, other Agile methodologies have also been proposed with practices to address particular limitations.

For example, one variation is called the Agile Unified Process, or AgileUP. As its name suggests, this Agile methodology combines Agile practices with the Unified Process model. AgileUP applies the principles of Agile to increase developer morale and improve collaboration. It uses Agile practices, such as test-driven development and small releases to supplement the basic Unified Process. Like the Unified Process, AgileUP uses the same structure of phases. The methodology emphasizes simplicity, empowering people, and customizing the methodology to suit each project’s needs.

In general, use a process, methodology, or practice that suits the needs of the product, team, and project. This may entail closely following something already established or starting there and customizing it as needed.

Other Agile methodologies include:

• Dynamic Systems Development Method
• Feature-Driven Development
• Behaviour-Driven Development
• Scrumban

Lean Software Design

One Agile methodology that has gained increasing attention is Lean Software Development. Its origin is inspired by the manufacturing industry where Lean production grew out of the “Toyota Production System.” At Toyota, their approach was used effectively to reduce waste in the production process and increase the quality of their vehicles.

Seven Principles of Lean

Lean Software Development, or Lean for short, provides an Agile methodology that enables the effective creation of better software. Lean is based on seven principles:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver at fast as possible
5. Empower the team
6. Build quality in
7. See the whole

These principles can be effective for both small and large projects.

Eliminate Waste

How can software development be wasteful? Consider the potential waste of time and effort that can arise from: unclear requirements, process bottlenecks, product defects, and unnecessary meetings. These are deficiency wastes.

Waste can also be disguised as efficiency because being “busy” does not always equate with being “productive.” A busy team not focused on developing core, required features can easily produce “extra” features that interfere with the core functionality of the end product. Coding can be wasteful if it is not planned to be a released. Anything that does not add value to the product is considered waste and should be identified and eliminated.

Amplify Learning

Explore all ideas sufficiently before proceeding with actions.

Do not settle and focus on a single idea before fully exploring other options. This principle seeks to find the best solution from a number of alternatives. Lateral thinking generates alternative approaches, and the more alternatives that are considered, the greater the likelihood that a quality solution will emerge. The biological mechanism of natural selection is a good metaphor for amplified learning. The most successful solutions emerge from the widest variety of alternatives. This exploration will lead to building the right product.

The principle also encourages running tests after each build of the product. Consider failures as opportunities to amplify learning on how to improve.

Decide as Late as Possible

Unless you actually need to make a decision right now, don’t make the decision yet.

Deciding as late as possible allows the exploration of many alternatives (amplify learning) and selection of the best solution based on the available data.

Early, premature decisions sacrifice the potential for a better solution and the “right product.”

Deliver as Fast as Possible

There is a relationship between Lean principles. Eliminating waste requires thinking about what you are doing; therefore, you must amplify learning. Amplified learning requires adequate time to consider alternatives; therefore, you must decide as late as possible. Deciding as late as possible requires focused productive work; therefore, you must deliver as fast as possible.

Delivering as fast as possible is chiefly concerned with evolving a working product through a series of rapid iterations. Each release can focus on core product features, so time and effort are not wasted on non-essential features. Frequent releases provide opportunities for the client to give feedback for further refinements.

Empower the Team

The best executive is one who has sense enough to pick good people to do what he wants done, and self- restraint enough to keep from meddling with them while they do it.

• Theodore Roosevelt

The first four Lean principles deal with the process of developing the right product. The remaining three principles describe how the process can be made efficient.

Lean aims to empower teams that follow its practices. It encourages managers to listen to their developers, instead of telling the developers how to do their work. An effective manager lets the developers figure out how to make the software.

Build Quality In

Aim to build a quality product.

Ways to build quality software include: conducting reviews of the work products, preparing and running automated tests, refactoring the code to simplify its design, providing useful documentation, and giving meaningful code comments.

Developing a quality solution reduces the amount of time developers must devote to fixing defects. By proactively applying this principle to build quality into the product, the development team eliminates waste in time and effort.

See the Whole

Maintain focus on the end-user experience.

A quality product is cohesive and well designed as a whole. Individual components must complement the entire user experience.

Additional Principles from Lean Software Developers

Mary and Tom Poppendieck wrote about these seven principles in their 2003 book, Lean Software Development: An Agile Toolkit. Over time, the Lean community has added other principles.

Use the Scientific Method

Initiate experiments to collect data and test ideas.

This principle encourages software product managers to base product features on real user data, rather than relying on hunches, guesses, or intuition. Collecting and analyzing this data allows clients and software developers to make informed choices about the product. Gain credibility by backing potential decisions with data.

Encourage Leadership

Enable individual developers to be courageous, innovative, inspirational, and collaborative. This principle extends empowering the team to bring out the best in each person on the team.

Warranty

Mary and Tom Poppendieck wrote this warranty in their 2003 book, Lean Software Development: An Agile Toolkit:

Lean principles are warranted to be tried and proven in many disciplines, and when properly applied, they are warranted to work for software development. Proper application means that all of the lean principles are employed and that thinking tools are used to translate them into agile practices appropriate for the environment. This warranty is invalid if practices are transferred directly from other disciplines or domains without thinking, or if the principles of empower the team and build integrity in [emphasis added] are ignored (p. 186).

In essence, it will not work to use controlling management practices to enable Lean. While the core of Lean is about eliminating waste and improving the product, the most effective way to achieve that is to empower the development team to implement the product the way they want and ensure quality in the product’s construction.

Kanban

Kanban involves a technique to organize and track project progress visually, which is widely used even outside Agile or Lean software development. Kanban is a Japanese word, which loosely translated means board or signboard. So, the Kanban technique uses a board, with a set of columns labeled by the stages of completion.

Tracking Tasks

A Kanban board can track the status of tasks completed by a team. So, for simple tasks, suitable column labels for the stages of completion would be “To Do”, “Doing”, and “Done.” Initially, all the required tasks are written on sticky notes and placed in the “To Do” column. As work proceeds and a task to do enters the “doing state,” its sticky note is pulled from the “To Do” column to the “Doing” column. When that task is done, the sticky note then moves from the “Doing” column to the “Done” column. For the required tasks, the board easily shows their states at a glance to the entire team. The team has full visibility of what needs to be done, what is being done, and what has been done. It is motivating to see the tasks march steadily across the board and useful to see when a task appears blocked.

Tracking Product Requirements

A Kanban board can be used effectively with Scrum. For example, the board above can track the status of the developer tasks that are planned to be done within a sprint. As well, a different Kanban board can track the status of individual requirements on the product backlog through the stages of being considered “done” in Scrum. Here, example column labels for the stages of completion could be: “Backlog,” “Analysis,” “Design,” “Tests,” “Coding,” “Review,” “Release,” and “Done,” following the phases of some software development process. Initially, the requirements on the backlog are written on sticky notes and placed in the “Backlog” column. As work proceeds, the requirements march across the board, eventually landing in the “Done” column. The requirements will move at different rates across the board toward completion.

In general, a requirement stays in a certain intermediate column until the team actually has the capacity to start the next stage for it. That is, a requirement is generally “pulled” into the next column. However, one tactic is to have a special “Next” column just after “Backlog”, so that a client or product owner can take a high-priority requirement off the backlog and explicitly “push” it into the development process to be worked on in a sprint. In this way, Kanban can be used to organize work as well as tracking work.

Client Needs and Software Requirements

Course Overview

Upon completion of this course, you should:

• Be able to explain and create clear requirements in order to drive effective software development.
• Understand different types of requirements, and how to properly adapt to changes in product requirements.
• Be able to visualize client requirements using low-fidelity prototypes such as wireframes and storyboards.
• Be able to identify and characterize different kinds of users and their needs.
• Be able to maximize the effectiveness of client interactions.
• Be able to express requirements with the help of tools such as user stories, acceptance tests, product backlog, and story maps.
• Know how to assess requirements for quality and clarity.

Introduction to Requirements

Upon completion of this module, you should be able to:

• Describe and recognize what a requirement is,
• Describe the types of activities associated with requirements: elicitation, expression, prioritization, analysis, management,
• Tell the difference between the different types of requirements: business requirements, business rules, user requirements, functional requirements, non-functional requirements, external interfaces, physical settings, and developer constraints,
• Recognize that changes are common to requirements,
• Describe the concepts of vision, and scope,
• Describe and defend against scope creep,
• Understand the concept of managing expectations, and
• Understand the difference between design and requirements.

Introduction

Welcome to the Client Needs and Software Requirements course, part of the University of Alberta’s Software Product Management Specialization. This course will provide fundamental elements to the specialization and will serve as one “leg” in the inukshuk that depicts the structure of our specialization.

In the introductory course, you learned that making better software involves three goals:

• The right product
• Done right
• Managed right

The right product means meeting the needs of your clients and end-users and not just their wants. This involves understanding the problem they need to solve, and the tasks they need to accomplish with the software.

To achieve done right and managed right, software development must start with a quality set of software requirements, which are later planned, designed, implemented, and tested.

In this course, you will learn how to elicit needs from your clients and end-users. You will also learn how to express these needs as a quality set of requirements to initiate software development and planning activities.

There are four modules in this course.

Module 1 will cover:

• Types of software requirements
• How to handle changes to software requirements
• How to avoid scope creep
• The fuzzy boundary between requirements and design

Module 2 will cover:

• How to outline client and end-user needs
• The role of use cases in designing a product
• The visual design techniques of wireframes and storyboards

Module 3 will cover:

• How requirements become more functional within an Agile framework
• The use of user stories and acceptance tests to express and verify requirements
• The use of a product backlog to prioritize requirements
• Creating story maps to organize requirements

Module 4 will cover:

• Criteria for quality requirements
• How to make requirements as clear as possible

The techniques you learn through this course will help you create a better software product suited to the needs of your clients and end-users.

What is a Requirement?

One of the most critical aspects of Software Product Management deal with conditions known as requirements. Many definitions have been developed to describe “requirements.” A requirement is most easily understood as a specific description of your client’s needs, which can be used to help create a real-world product.

The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2). (IEEE, 1990).

Well-defined requirements help make sure client needs are understood and addressed and also

**DID YOU KNOW? **

The Institute of Electrical and Electronics Engineers (IEEE) is an international professional association of engineers, scientists, software developers, and information technology professionals, among others.

The IEEE is well known for developing standards in both the computer and electronics industry.

help detect potential problems before they become large and expensive to fix.

Requirements Activities

In the previous course, Software Process and Agile Practices, software development is an organized process, featuring a series of phases. Grouped within each phase is a series of one or more activities—sets of related tasks. Requirements are established during activities at the beginning of a project. It determines the purpose of a product and how the product can meet that purpose.

This course will explore five important requirements activities:

1. Eliciting requirements
2. Expressing requirements
3. Prioritizing requirements
4. Analyzing requirements
5. Managing requirements

With these activities, the right requirements can be established, written in proper form, and even improved.

Eliciting Requirements

The activity of eliciting requirements is an interactive and investigative process, which occurs when meeting with the client and users.

Clients often have ideas about what features they would like in a product and what these features should look like. Many clients, however, have limited knowledge of how software is built and vague ideas regarding what makes a project successful. It can be difficult then for clients to understand what they truly require in a product. It is the role of the software product manager to help the client figure out what they “want” and what they “need.”

A “want” is usually a functionality or feature that the client would like the product to have, which may add value, but is not necessarily core to the product itself. A “need,” on the other hand, is a core functionality that the product must have in order to fulfill the product’s purpose. Needs should take priority in product development.

The best way to discover and develop “needs” and “wants” with your client is through eliciting requirements, where you engage in discussion about the product with your client. Through discussion, the software product manager and team can help provide insights on what the client “needs” and “wants” the product to do, and how these goals can be feasibly achieved. It may be that the initial vision the client had of the product will have changed, but through involvement with the software product team, any changes should feel proactive and the client should feel reassured that the team understands users’ needs.

Note that eliciting requirements as “needs” and “wants” does not necessarily mean that all the client’s features and ideas that fall in the “want” category are not doable or should be dismissed. In fact, these ideas may be very good. But it is the role of the software product manager to make sure that the goals are feasible, client expectations are realistic, and the product produced is the best possible result.

Eliciting requirements should not be confused with “requirements gathering.” “Requirements gathering” is the more passive approach of simply asking the client what they would like done, and it often puts the development team in a reactive process. Eliciting requirements, however, engages in in-depth discussion and collaboration from the start of product development, so both the client and the development team work together to build a successful product.

Expressing Requirements

Once client needs have been established by eliciting requirements, the activity of expressing requirements comes into play. Expressing requirements involves framing the requirements identified through discussion in a way that allows a product to be built.

Often, requirements are first described through notes from meetings with clients. From there, better and more concrete representations can be used for expressing requirements. Typical representations include use cases, user stories, or storyboards, among others. These are often tailored to the project. They could be simple or complex, textual or visual. It is up to the software product manager and team to determine and use representations that would work best for the project at hand.

Prioritizing Requirements

Once a vision of what needs to be done for the project has been established through both eliciting and expressing requirements, it is important to prioritize client needs, especially in Scrum methodology.

Questions to help establish priorities include:

• What requirements must be completed for the project and product to be successful?
• What requirements should be done? In other words, what is important but is not as time-critical or could be satisfied another way or at a later time on the project?
• What could be done to improve the project or product but is not necessary? These priorities are usually only included if both time and resources allow for it.

MORE INFORMATION

The questions outlined here closely follow the MoSCoW method of prioritization, developed by Dai Clegg. This method is used to help reach an understanding with clients on the importance of each requirement. “MoSCoW” is an acronym for the categories of “Must have”, “Should have”, “Could have” and “Would like but won’t get.” By asking the questions suggested here, requirements can be placed in these categories.

Analyzing Requirements

The process of examining the listed requirements of a project to ensure that they are clear, complete, and consistent is known as analyzing requirements. Analyzing requirements helps ensure that the product is the best one possible. It is an important process, and a constant one. A project must be continually evaluated and requirements improved as it progresses. This adaptive nature is important in Agile systems.

Analyzing requirements helps to resolve any potential conflicting requirements or to identify problems between requirements that might not be easily seen at first glance. It also ensures that the requirements identified truly reflect and relate to the product being built.

Managing Requirements

The activity of managing requirements is also a continuous process. It involves the organizing and re-organizing of requirements and possibly reusing subsets of requirements in different stages. It also involves keeping track of priorities, analyses, and changes in requirements. This is very important because everything is connected in a project. If something changes in one requirement, it will affect other requirements and the development of the product.

Managing requirements also means ensuring that the identified requirements are central to the many processes of product creation, including coding, testing, and change logs.

Types of Requirements

Now that we’ve covered what requirements are and the activities involved with getting them right, let’s dive into a little more detail and introduce some different types of requirements.

This course will cover the following types of requirements:

• Business requirements
• Business rules
• User requirements
• Functional requirements
• Non-functional requirements
• External interfaces
• Physical product settings
• Development constraints

While business requirements and business rules can influence the project, it’s user requirements, functional requirements, and non-functional requirements that are considered the most essential requirements. Finally, external interfaces, physical product settings, and development constraints are requirements that add context for design and implementation of the product.

Business Requirements

There are many possible definitions for business requirements. In this course, business requirements refer to those requirements that involve the purpose of the project. In business requirements, goals are presented in concrete and specific terms. These goals are usually tangible or quantifiable business values that can be used by business analysts.

An example of a business requirement might be: “The client needs to reduce errors in orders made to their company by 25% by the end of next year to raise their yearly revenue by $10,000.”

Business Rules

Business requirements should not be confused with business rules, although they are often associated. Business requirements deal with why the project was pursued, while business rules are constraints on how the product will function. Business rules are sometimes necessary to make a project appropriate or successful. They are often budgets, policies, guidelines, or regulations.

Examples of business rules include:

• Government or legal regulations
• Privacy policies
• Brand uniformity requirements

User Requirements

Users or end-users are the people who will use the software once it has been created. User requirements are the tasks that these users can accomplish with the product, or what the product can do for the user. User requirements are very important requirements to the project, if not the most important. They are part of the core functionality of the product. For this reason, determining user requirements is usually very time consuming.

There are many methods for expressing user requirements, including:

• Use cases
• User stories
• Storyboards
• Scenarios

Scenarios refer to cases where the client or end-user describes user requirements in their own words. These descriptions can sometimes be vague or non-specific. It is part of the role of the software product manager to help organize and refine their needs in more concrete manners, so the development team knows how to best build the product.

Use cases, user stories, and storyboards are explored in more depth below.

Functional Requirements

Functional requirements are those behaviours that the developed product should do or support. These are usually expressed as inputs into the product, outputs of the product, or a description of the behaviour itself. For example, input might be data related to a user’s online purchase, including name, address, item purchased, and payment information. The output in this scenario might be a notification email after the transaction is performed.

Often, functional requirements need to be expressed with depth and specificity. Information flow diagrams are a graphical technique commonly used to show how data flows throughout the system and the dependencies of all the system components. Together, an information flow diagram shows how the entire system functions.

The following is an example of an information flow diagram for a customer using a credit card with a product, and where the credit card information is verified before a receipt is generated for the user.

Information flow diagrams or data flow diagrams are visual techniques used to show how information or data moves through a system. The information may change as it moves from input to output of the system. These diagrams are useful for show how users can interact with the product.

Information flow diagrams can be partitioned into levels that show progressive flow and increased detail. Information flow diagrams are valuable tools because they can describe the system process without relying on details related to computer systems.

Below is an example of the format of an information flow diagram might take.

Non-functional Requirements

In addition to functional requirements, there are non-functional requirements that describe how well a product must perform. They are also known as quality requirements for this reason. Non-functional requirements address product issues including accuracy, dependability, security, usability, efficiency, performance, and maintainability.

Drawing on the online purchasing example used in functional requirements, a non-functional requirement in the same scenario would be that emails should be delivered to users within two hours of purchase. Non-functional requirements are usually complementary to functional requirements.

External Interfaces

External interfaces requirements refer to those requirements related to how the product is situated within a larger system. In other words, external interfaces do not concern themselves with the physical environment of the product, but rather they are concerned with the relationship of the product to other entities outside the product.

For example, a software application that retrieved information from a remote database to display to users sits between the entities of the database and the end-user. An external interface is used between each one. Interfaces also involve the way connections are made through media, protocols, formats, and levels of compatibility.

External interfaces can be represented within data flow diagrams that show all the components of a product, including outside entities. These data flow diagrams make explicit reference to the flow of data from other entities and the product within an entire system.

Physical Setting

Physical setting requirements refer to how the product needs to be designed in order to function in its physical environment. For example, if a product was being developed for underwater exploration, it would need to be waterproof. Similarly, if the product was designed for use in the desert, or in Antarctica, it would need to withstand and function in those environments.

Development Constraints

Development constraints affect everything from implementation technology, conventions, documentation, and the process used to develop the product. They generally refer to constraints related to creating the product, such as which devices or platforms will be supported, or how much memory, bandwidth, or processing power the product is limited to using.

It is beneficial to address development constraints as late as possible in the specification phase because technology changes rapidly.

Changing Requirements, Controlling Scope

When a product is designed, it is guided by a principle known as product vision. The product vision is what outlines the value of a product to the client and its place within the wider market. It relates to the purpose of the product, as well as the problem or need the product sets out to solve. Any changes that occur in the project should fall within the vision of the product. In other words, changes to the project should not change the purpose of the product.

Visions can become problematic if they are not realistic. Scope is defined as what a project can realistically achieve. It is an important aspect of the project that has the power to greatly affect development teams and product managers.

American software engineer, consultant, and author Karl Wiegers has defined both vision and scope. The definitions are:

Vision is a “long-term strategic concept of the ultimate purpose and form of a new system.” (Wiegers, 2012, p. 1)

Scope is what “draws the boundary between what’s in and what’s out for the project.” (Wiegers, 2012, p. 1)

We can see that the two concepts are interrelated and why scope is so important to project development. Defining the scope ensures that the project undertaken is not only possible but also successful.

Defining scope is an important part of the project, and it is best done during the requirements elicitation activity of the project. It is also important to manage client expectations during this process and not to over-promise what the development team can realistically deliver. A good strategy for managing expectations is to identify what will not be included in a product, so client expectations are clear.

Scope creep* happens when the scope of a project grows as the result of an increase or change in requirements. Consequently, the likelihood of project success usually significantly lowers over time.

For example, the vision of a project could be designing a game to teach cardiopulmonary resuscitation (CPR) to users. A change in scope could involve switching the platform on which the game is designed once development has already started. This change could drastically affect the success of the project.

Changes are common to software requirements and need to be accounted for. Strategies for defending against scope creep include:

• Making expectations clear between client and team.
• Drawing the scope with the client through tools such as use case diagrams.
• Asking the client to prioritize requirements so that the most important ones can be developed early.
• Asking “Is this in scope?” when refining requirements to avoid spending excess time working on unnecessary requirements or capabilities better suited to later releases.

Providing concrete time frames for developing requirements with clear beginning and end dates also helps determine whether the requirement is realistically doable and within the scope of the project. Estimating time frames is a skill that software product managers refine and improve with time.

A core principle of the Agile manifesto is evaluating each proposed change on a case-by-case basis and how that change might affect the project. Changes should be introduced to increase the project’s business success. Any accepted changes should also entail revisions in estimates and plans for product development.

Requirements and Design

In Agile, sometimes the lines between forming requirements and designing a product become blurred. Requirements focus on what the product is designed to do, while design focuses on how the product can satisfy user needs.

It is common for both requirements and design to be worked on simultaneously, and requirements could be formed with elements of design in mind. The use of techniques such as product drawings can also help identify whether requirements fit together as a whole and are correct, consistent, and clear. Often, clients will also think of their product and focus on desired design characteristics. It is part of the role of the software product manager to help the client understand what their true problems or needs are in that case.

The software product manager must also be careful not to impose unnecessary constraints on the product by blurring requirements and design. For example, an aspect of design such as the coding language or interface features could potentially limit a product, and it should not be confused with being a requirement.

Strategies for avoiding problems in blurring requirements and design include asking the following questions:

• Is the solution just a possible option?
• Is the solution the only one possible?
• Is the solution addressing the wrong problem?
• Is the solution just to attract developer interest?
• Is the client more “solution focused”?

Client Interactions

**Upon completion of this module, you should be able to: **

• Describe who a user is, and tell the difference between primary, secondary, and tertiary users, including stakeholders.
• Explain strategies for involving clients in software development, including:
  • Managing client expectations,
  • The kinds of questions to ask to discover and refine requirements and needs,
  • The benefits of using a glossary.
• Create a use case description, including: name, actors, goal, trigger, pre-condition, post-condition, basic flow, and exceptions.
• Create a wireframe and recognize the requirements it expresses.
• Create a storyboard and recognize the requirements it expresses.

User Considerations

When designing a product, one of the most important things to take into consideration is the end-user. End-users are the people who will use the product. They are among the stakeholders of the project.

A stakeholder is anyone affected by or who has an effect on the success of the project, such as end-users, clients, managers of end-users, and system administrators. A successful project addresses the needs of all stakeholders.

There are three types of stakeholders or users: primary users, secondary users, and tertiary users.

Primary users are end-users, or the people who will use the product. Secondary users are those people who will occasionally use the product or use it through an intermediary. They may not be the target audience, but they could be related to the target audience in some way, such as parents of children who use a product designed for children. Tertiary users are those who are affected by the use of the product or make decisions about the product, such as clients.

A product should be designed to be something users can navigate and want to use. This is primarily accomplished through good user interface (UI) design. UI is what is seen when using the product, and it can encompass anything an end-user interacts with—features such as windows, buttons, scrollbars, checkboxes, and text boxes. Good UI design is important. If there are many similar products on the market, users will easily move on to another product if they do not like what they are currently using. An entire discipline known as human computer interaction (HCI) studies how end-users interact with technology products. More information on HCI is available in the course resources.

A number of issues that may arise in considering user interactions include:

• Users have an inability to express what they need
• Users are biased by previous experiences; e.g., a user is more likely to use a bad interface that they are familiar with rather than a new one, even if the newer one is actually a better product
• Developers sometimes have trouble seeing through a user’s point of view because of their advanced knowledge of technology

Creating an intuitive, user-friendly interface is key to addressing many of these issues. A good strategy to consider is to design a product for both beginner users and expert users. In general, the design will then accommodate intermediate users as well.

When designing software, it is also important to consider the numerous limitations users are faced with. These limitations are related to human limitations. They include:

• Perceptual or sensory limitations, which are caused by restrictions of the five senses. Colour blindness is an example of a sensory limitation.
• Physical limitations, which affect how a user physically interacts with or uses a product. An example is left- or right-handedness.
• Cognitive or memory limitations, **MORE INFORMATION **

where people can only remember so

many things at once, so it is George A. Miller, one of the founders of the field of important to use visuals in design cognitive psychology, discovered that humans have an that are familiar or suggestive to help average limit for short-term memory capacity. People identification. can remember between five and nine things, with seven

being the average. Distractions limit memory even more.

• Cultural limitations, which

encompass how different cultural Good product designers understand this memory backgrounds of potential users can limitation and work with metaphors and symbols that affect interpretation of design users will be familiar with, so there is less for them to elements, such as symbols and remember!

icons, layout, multimedia, and

translation needs.

More information on cultural limitations is available in the course resources.

Involving Clients and Users

In Eliciting Requirements, the importance of involving clients was emphasized. A good software product manager and development team do not simply gather ideas from clients but actively collaborate with clients. Consequently, client ideas may change from the outset of discussions, but with input from both the team and the client, the best possible product can be made.

Requirements can also come from other sources, including:

• Interviews with end-users
• Feasibility studies with focus groups
• Observing how end-users use the product
• Consulting previous products

Involving clients in collaborative discussion over requirements, usually in face-to-face meetings, helps manage client expectations. By being involved in discussion, clients are aware of realistic goals and timelines, what will and will not be done in the product, and subsequently they can prioritize requirements.

Below are some key points to remember when interacting with clients.

Try to keep a good balance between being assertive and open to client ideas and perspectives. It is not good to just accept ideas passively. The software product manager and development team should suggest ideas and perspectives in meeting with the client, but they should not enforce their viewpoints aggressively.

The software product manager should try to provide structure in conversations with the client about requirements. This will help the client organize his or her thoughts. Care must be taken not to steer the client, however.

Clients sometimes come with set ideas about what they want in a product. However, they sometimes don’t know what is possible technically, or they have ideas that would actually be hard for end-users to understand or use. The software product manager should try to understand why the client has set upon these ideas. A good way to do this is to ask the client to explain how they envision an end-user interacting with the product. Once the client’s reasoning is understood, alternative ideas can be

suggested. It may also be useful to TIP: A good way to involve clients and to understand their politely highlight why certain ideas may requirements is to ask good questions!

not work. This can also be done

through exploring limitations and Good questions are open-ended and cannot be answered different scenarios. with a simple yes or no. Questions that ask “why?” are

particularly good, because they encourage a client to Note that it is the role of the software analyze and identify their core needs. Simon Sinek’s Ted Talk product manager to make sure a client on asking “Why?” gives a good explanation of what makes is well informed and understands their this question valuable, which is available in class resources. options. However, at the end of the

day, the client is the one who makes “What do you want?” or “What are your requirements?” are the key decisions regarding less useful questions because they are too broad and do not requirement, even if the development provide good structure for understanding client needs.

team would prefer to go a different

route.

Requirements should be revisited often with the client. After a first meeting, for example, it is a good idea to show the client mock-ups and prototypes produced from initial discussions. With these concrete tools, clients can more readily identify what they like in a product, what they want, and what they dislike. Revisiting requirements also allows clients to answer questions, advise on design choices, and provide feedback.

TIP: It is good practice to number requirements with unique identifiers throughout the project, so they are easy to reference as the project develops!

An important tool for interacting with clients is the use and creation of a glossary. A glossary is a list of terms and their definitions that relate specifically to the product being built. It is common for many different terms to be generated for the same thing if a glossary is not used and agreed upon, which can make discussions confusing.

In summary, key aspects to remember in customer interaction include:

• Involve the client through meetings and continuous re-visitation of requirements.
• Use other information sources, such as end users.
• Ask good questions.
• Be assertive and open in client interactions.
• Clearly communicate realistic requirements and timelines to manage client expectations.
• Use common terms via glossaries.
• Keep track of requirements
• Remember that it is the responsibility of the software product manager to clearly communicate the pros and cons of requirements, but the client is the one who must make the key-level requirement decisions.

Use Cases

Use cases, developed by Ivar Jacobson in 1986, are a good tool for understanding a product. They can be defined as a way to identify, clarify, and organize details of a task within a product. Uses cases take place in particular environments to achieve particular goals. In other words, it’s a way of explaining a set of sequential interactions users might have with the features of a product.

A good use case outlines the proposed task from the point of view of a participating actor (usually a user), and it should not require deep knowledge of technology to understand. Use cases may be presented in tables as outlined below.

Use case elements are defined as follows:

For example, a completed use case would look like:

It is helpful to depict the use cases of a product with a diagram (see below). Use case diagrams are high-level, visual representations outlining all the tasks supported by the product being created. Actors and their respective uses cases are also represented. Overall, the diagram should show the entire product, tasks that may be undertaken while engaging with the product, and roles supported by the product.

Use cases are a useful tool for software product managers and their development teams when establishing requirements. By creating use cases and sharing them with clients, the project has more definite guidelines, and development tasks become more organized and elaborate.

Wireframes

One of the most important techniques of product development is the use of wireframes. A wireframe, also known as a mock-up, can be thought of as a kind of early blueprint. It is a basic visual representation of the product. See the example below of what a biography web page might look like.

Wireframes are used for many purposes. These include:

• getting an idea for what will be developed
• demonstrating ideas to clients or users and encouraging their feedback and involvement
• communication among the development team
• helping the client or users communicate with the software product manager and team (some people may find it easier to sketch out their ideas to describe them)

Although a visual representation, a key aspect of wireframes is their simplicity. Wireframes are not meant to be a demo of the interface of a product but rather outline basic functionalities and end-user tasks. This means that wireframes do not use colours or images. In fact, it is important that detailed design features do not creep in to wireframes.

Instead, wireframes may suggest things like where buttons, text fields, and images are placed. The elements displayed should theoretically allow a user to do a task with the product. As in a blueprint for a house, for example, details such as wall colours or lighting fixtures are not outlined. Later, detailed user interface (UI) design can develop further.

Wireframes are usually developed quickly after an initial discussion with the client regarding requirements and presented thereafter. Clients then have a chance to see an early version of what their product might look like and provide feedback. It also ensures that both the client and development team are working towards the same vision.

TIP: There are many tools to help develop wireframes! You can always draw images by hand and then scan them, but there are many drawing tools on the computer that can help you create wireframes.

Some examples are:

• Google Docs
• Microsoft Powerpoint
• Balsamiq (online tool available at https://balsamiq.com/)
• OmniGraffle (a paid app available at https://www.omnigroup.com/omnigraffle/)
• Wirify (a tool which turns any web page into a wireframe, available at http://www.wirify.com/)

Some examples of wireframes can be found at http://wireframes.tumblr.com/

Storyboards

Another technique used to help in forming requirements are storyboards. Many disciplines make use of storyboards. In software development, storyboards are sequential, visual representations of an interaction with the software product.

There are two main types of storyboards. Both types can be helpful for discussions between clients and the development team. Storyboards help to elicit further requirements of the product and refine existing ones.

The first type of storyboard describes high-level user experience with the product. This type of storyboard tends to look like a comic strip, where each action is illustrated in the sequence or flow of using a product, including the decision to use the product and outcomes at the end of an interaction. If multiple features are offered in the product, then each should get a storyboard.

An example of this first type of storyboard appears on the following page.

Captains in the panels should read:

1. The Smith family decided to go to Brampton’s Pizza for a nice family dinner.
2. They are seated at a table and use the tablets at the table to browse the menu.
3. They browse the dishes on the application and place their order.
4. The cooks in the kitchen receive the order.
5. The food was delivered to the table once it was read and they have a nice family dinner.
6. Once they were finished their meal, the mother viewed and paid for the bill on the application.

Generally, the envisioned user, or participating actor (as described in use cases) in this type of storyboard, is given a persona. Personas provide more elaborate back stories to the participating actors, including details such as age, ethnicity, income level, job, personality, etc. Providing high-level details helps the storyboard address specific issues.

The first type of storyboard has many potential uses, including:

• Ensuring the entire development team is on the same page
• Enhancing the possibility of identifying features to improve or create in the software product
• Ensuring the vision of the product remains clear in its use
• Use in marketing or demos

The second type of storyboard combines wireframes and basic flow from use cases in order to show how the end-user interacts with the user interface of the product in detail. It is more closely related to software design.

It also shows all the sequences of user interaction with the product, and the outcomes of those interactions. Each state of the product during interaction is illustrated with a wireframe. The user interface element needed to get to the next state is also illustrated. Transitions between states are generally depicted with an arrowed line.

The second type of storyboard has many potential uses, including:

• Helping the development team to design requirements
• Helping identify what could be overly complicated or missing in supporting tasks the users perform
• Ensuring the development team is aware of the functionalities and feel of the product
• Guiding technical writers in creating training materials

Below is an example of the second type of storyboard.

Writing Requirements

**Upon completion of this module, you should be able to: **

• Describe requirements within the 12 Agile principles.
• Create a user story and recognize the format of a user story.
• Assess what makes a good user story.
• Recognize when a user story is too large (in other words, you should be able to recognize an epic user story), and why this is likely to occur in the specification phase.
• Create an acceptance test for user stories based on acceptance criteria.
• Explain what a product backlog is, and help prioritize user stories.
• Describe what product backlog is and how it works within Scrum.
• Create a story map, and identify the benefits of using a story map.
• Identify any missing or inconsistent user stories within a story map.

As we just saw, requirements can be expressed through techniques such as use cases, wireframes, and storyboards, but they can also be expressed through many written formats.

Agile Requirements

Client needs and requirements may be expressed within the philosophy of Agile Software Development. There are 12 principles of Agile Software Development, as explained in the Introduction to Software Product Management course and the Software Processes and Agile Practices course. These principles support the belief in Agile that software is dynamic. In other words, in Agile, software cannot be simply defined once and then created off that singular definition—it is constantly evolving.

In concurrence with this philosophy, clients often change their minds about product functionality. This can happen even in the middle of development. In Agile software development, however, changing requirements should be welcomed and expected. The ability to welcome changing requirements can make the difference between the success or failure of a project. Development teams should understand that although requirements are created with full intentions of following through, requirements also inevitably change.

According to Agile, face-to-face interactions with clients is key to ensuring requirements are right, even as they change. Requirements should be elicited in an open and collaborative setting, as discussed in Eliciting Requirements. Although the vision of the product should come from the client, software product managers often help narrow the vision and outline what requirements are within scope of the project. These meetings are also an opportunity for discussion of the inevitable changes in requirements. As explained in the Software Process and Agile Practices course, this is frequently practiced in Scrum.

Collaborative discussions with the client help to ensure that project requirements are the best possible, and they set the precedent for communication.

Requirements are an integral part of Agile. In turn, if Agile is followed in creating requirements, quality is enhanced.

User Stories

User stories are a major technique used to express requirements, like use cases, wireframes, and storyboards. User stories are special because they use a consistent format to express requirements that is easy to write, read, and evaluate.

User stories take the following format:

“As a ‘who,’ I want to ‘what,’ so that ‘why.’”

The “who” of the requirement is the stakeholder role for whom the requirement is being formed. The requirement should be written as if it is from this person’s point of view.

The “what” of the requirement is the specific task or functionality the stakeholder wants to achieve by using the product.

The “why” of the requirement highlights the goals or visions of the product, and it provides insight into the value or benefit of the requirement.

An example of a user story based on the restaurant example previously used in this course could be, “As a customer, I want to be able to identify dietary restrictions, so that I know I can eat the food I order.”

User stories are useful, as they provide a clear and structured way to express a requirement that also does not use too many technical details. Unlike freely formed requirements, user stories ensure the “who,” “what,” and “why” of a requirement are always accounted for. User stories are also useful because they are short and can be easily written on physical index cards or sticky notes. This practice allows easy organization of requirements, which can be re- organized when requirements change.

Classically, user stories were written on index cards. The front of the card contained the user story, and the back held the acceptance criteria, which we’ll cover later. With software build to help track software development progress, user stories are no longer constrained by the size of the card. However, when creating your user stories, keep in mind that shorter is usually better, as that forces you to make your requirements understandable and actionable.

If you have any doubts about the size of a story, try writing it on an index card in the format below. If you have trouble getting your ideas to fit, try re-wording things to be more clear and concise.

Although clients should write user stories, as they know best what they want in a product, software product managers often write or help write user stories because they are more experienced in doing so.

User stories can be evaluated using the mnemonic INVEST. A good user story outlines a specific software requirement in the product.

If a user story contains descriptions that are too vague or broad, and if it is difficult to estimate how long it will take or how it can be done, it is probably an epic user story. Epic user stories usually occur at the beginning of a project when the product is still developing and may not yet have definite form. This is due to the pattern

known as the “cone of uncertainty,” which Example of an epic user story:

suggests that the time estimates to develop a

user story become less accurate the further “As a customer, I want to pay for my bill, so I can into the future the feature is intended to be settle what I owe quickly.”

developed. Even experienced development

teams encounter epic user stories. This user story could be broken down into smaller

ones, such as:

In order to avoid writing epic user stories, it is § “As a customer, I want to be able to see a important to be able to identify when one has bill, with all of the items in that order, so I been created. If an epic has been identified, it can see how much my order will cost.”

can be broken down into smaller stories, § “As a customer, I want to be able to select which can be estimated. A good strategy to a “pay now” option when I view my bill, so avoid epic user stories is to provide just I can pay the bill immediately.”

• “As a customer, I want to be able to enter

enough information for a developer to my payment details for VISA and understand how to implement it, but not so MasterCard credit cards, so I can pay using much information that implementation details a convenient method.”

become part of the story.

Acceptance Tests

An acceptance test is used to verify whether or not the requirements of a user story have been completed. Acceptance tests are often used in the testable part of the mnemonic INVEST. A user story is considered satisfied if the test is passed.

Acceptance tests are evaluated based on a set of acceptance criteria. Acceptance criteria are simple with specific conditions used to check if a user story has been implemented correctly.

Clear, straightforward language should be used in creating acceptance tests.

Acceptance criteria are usually determined by the client’s specific needs. In order to turn acceptance criteria into an acceptance test, it is helpful to go through the steps of the criteria. Each test should assess one verifiable condition that makes up one small part of the user story. If all tests are passed, then the acceptance criterion is passed. If all acceptance tests are passed for all of the user story’s acceptance criteria, then the user story is considered

Building on the restaurant example used throughout this course, examples of acceptance criteria for the user story “As a customer, I want to be able to enter my payment details using VISA and MasterCard credit cards so I can pay using a convenient method” include:

• Payment can be made using a VISA credit card.
• Payment can be made using a MasterCard credit card.
• Payment can be made using an online financial service.
• When paying with a credit card, filling in the “card number” field auto-detects the card type.
• The customer sees only the relevant input fields, depending on the selected payment method.

To turn a criterion into an acceptance test, it is helpful to create a few steps. For example, for “Payment can be made using a VISA credit card,” tests could be:

• Insert a VISA card into a chip reader.
• Enter the VISA’s PIN number.
• Confirm the payment was accepted.

Going through these steps verifies the acceptance criterion.

successfully tested.

Acceptance tests have many other added benefits. They allow the development team to view requirements from user perspectives. They also help with determining functionality of the product, as they provide details not present in the user story. These details can help outline developer tasks and how those might be finished. Acceptance tests can also help avoid epic user stories. An excessive number of acceptance criteria suggests that a user story should be broken up into smaller pieces.

Like user stories, acceptance tests should be developed by the client with help from the software product manager and development team.

Product Backlog

A product backlog is a set or list of software features that the software product manager and development team plan to develop for a product over the course of a project. They are a means of organizing work, prioritizing tasks within the project, and planning those priorities. Product backlogs are a popular technique because they provide a lot of flexibility for both clients and development teams. They are critical to Scrum and therefore Agile.

Features in product backlogs include work tasks (physical jobs that must be done on the project but are not necessarily related to developing product features), knowledge tasks (work for parts of the project that need to be learned), bugs (errors in product code), and most commonly, user stories. All tasks in product backlogs tend to become more refined over time.

In order to create a product backlog, after user stories are created, they should be placed in a list. Each user story should also be assigned a unique identifier. Identifiers can be as simple as sequential numbers.

The next step in creating a product backlog is to prioritize the user stories and features. The process of prioritization helps clients identify their needs and wants. It also gives developers perspective and focus by highlighting what is most important in a project. Prioritization also helps determine what features can feasibly be accomplished in a project with technology and given resources.

As prioritization is important for the entire team, prioritizing user stories in product backlog is best done through discussions between clients, the software product manager, and the development team. Why a user story is important will be clearer to everyone through such discussions, as well as why an effort estimate has value.

Using the product backlog, the development team can start to plan the project using priorities as reference points (for more information on this, see the Agile Planning and Software Products course). User stories from product backlogs are grouped together into units of work to be done at certain time intervals. In Scrum, these intervals are known as sprints. The most important features from product backlogs should be finished earlier, while less important ones can be finished later.

Product backlogs are very flexible in light of this kind of development. Scrum focuses on developing one sprint at a time. Although the sprint in development should not change, sprints beyond the one being worked on are able to change. At the end of a sprint, clients can evaluate the work done and add new user stories or requirements for the product, or change the priority of existing user stories or requirements. The next sprint can be adjusted accordingly.

Product backlogs will therefore change over time and can become smaller, bigger, or have changed orders. Such adaptability and versatility is encouraged in Agile methods.

Story Maps

Story maps are used to organize requirements and help structure a project. Story maps support change on a higher level than even product backlogs. They present product backlogs in a visual manner, with user stories grouped into specific functional categories. By covering and prioritizing user stories across multiple categories, story maps provide holistic views of the product being developed.

Story maps have a specific structure. They are created as sets of columns. Each column represents a category for grouping user stories together. Within each column, user stories are prioritized from most to least important. This structure allows the client, software product manager, and development team to see the highest priority user stories for an entire project. While a list of requirements with the structure of a product backlog might be overwhelming, story maps turn such lists into manageable, organized sets of features to be implemented over the course of a project.

Below is an example of what a story map structure might look like.

Story maps have many benefits, including:

• Simplifying prioritization of user stories
• Giving product backlogs a trackable, visual feel
• Giving perspective on how user stories may relate to one another
• Helping identify what might be missing from each category
• Providing context for developers by showing that other simple functionality may best be implemented before more complex work
• Providing a holistic view of the product by not allowing focus on one category only, but instead emphasizing the multiple functionalities (or categories) of most products
• Giving a better understanding of how the product will develop and fit together over stages—it is possible to see how a product will evolve row by row, which could save time over the course of the project.

Story maps are a good example of the Agile principle of building working software because of its emphasis on multiple functionalities.

It is important to remember that a story map is not a Kanban board. A Kanban board, as discussed in Software Process and Agile Practices, is a visual tool used to display the project’s current state and to keep track of progress of project tasks. In contrast, a story map is used only as a tool to plan and organize user stories. Story maps, however, are not full-fledged development plans either.

Quality Requirements

**Upon completion of this module, you should be able to: **

• Recall the INVEST mnemonic
• Describe the criteria used to assess whether or not a user story is good: correct, complete, clear, consistent, feasible, and traceable.
• Recognize a “correct” user story.
• Recognize when user stories conflict.
• Identify an ambiguous requirement.
• Recognize common terms that might contribute to making a user story ambiguous.
• Clarify an ambiguous term within a user story.

Criteria for User Stories

It is possible to evaluate the quality of user stories using a set of criteria. Quality user stories are important for guiding development in order to avoid mistakes and confusion. Accordingly, there should be no missing user stories, and existing user stories should be easy to understand and free of ambiguity.

The previous module covered the INVEST mnemonic. The INVEST mnemonic outlines the criteria that quality user stories should meet. To build on that lesson, there are some additional criteria that user stories should meet in order to ensure quality.

High quality user stories help to keep development on track and to avoid mistakes and confusion. For example, user stories should be defined in such a way that they are small and simple to understand, provide value, and can be clearly tested as being done.

Beyond the INVEST mnemonic, there are several other criteria that requirements and user stories should meet in order to ensure quality:

Ambiguous Requirements

Requirements may encounter problems if they are ambiguous. A requirements can be ambiguous if it has multiple interpretations, or if it does not provide all necessary details. This leads to miscommunication between the development team and the client, and potentially incorrect software. Avoiding ambiguous requirements saves time and money.

It is understood that many readers of this text are not native English speakers. Because of this, the ambiguous words that will be covered in this lesson have been divided into several categories of ambiguous words, in the hope that you will be able to translate the rules into the language that you are conducting business in.

TIP: The words explored in this lesson do not always lead to ambiguous requirements, they just need to be used appropriately. You may need to add some additional information to remove the ambiguity.

The eleven categories of ambiguous words that will be explored in this lesson are:

• Indirect Words · Comparatives
• Vague Words · Quantities
• Persuasion Words · Pronouns
• Completion Words · Positional Words
• Qualifiers · Temporal Words, and
• Joining Word

Indirect Language

“May” The verb “may” is ambiguous because it is passive language. It could imply

that something must be as described, or it could imply that something could be as described or could be something else entirely. For example, Consider the example, “As an online poker player, I may win money, so that I am rewarded for winning games.”

In this example, it is unclear as to the circumstances in which the online poker player wins money. You clarify this user story by specifying that information. Better is rewriting this user story to be, “As an online poker player, I receive money when I win a game of poker against my opponents, so that I am rewarded for winning games.”

“Will” “Will” is a sign of ambiguity if the statement does not specify when the event

will happen. Is it all of the time or just some of the time? If an event will occur every single time, it is better to use the word “must”. If the event only occurs some of the time, specify the conditions in which it does.

Vague Words

Persuasion Words

Completion Words

Qualifiers

Comparatives

Quantities

Pronouns

Positional Words

Temporal Words

Joining Words

There are many other words that may create ambiguous requirements, but the ones listed above are the most common. If these words are used, the client should be asked to elaborate.

Scanning your user stories for specific words as signs of ambiguity is not the only way to determine if you have unclear requirements.

Another great way to make sure both your requirements and your glossary are free of ambiguities is to replace terms from your user stories with their glossary definitions. Do your user stories still make sense? Does your glossary definition represent the term properly? By doing this, you may discover that you need to add more terms to your glossary, redefine some terms in your glossary, and/or rewrite some of your user stories.

Unclear language can also arise during discussions between the client, software product manager, and development team. It is important for the software product manager to ask questions to clarify discussions. Good questions include examining the truth of presented facts and asking for elaboration on uncertain terms or certain points of perceived needs and requirements. Determining what the client means and why is important to creating quality requirements.

Agile Planning for Software Products

Course Overview

Introduction

Welcome to the Agile Planning for Software Products course, within the Software Product Management Specialization. This course will focus on agile planning techniques. These techniques ensure that the software product project is managed and organized properly while also being adaptive to change.

1
2
3
4
5
6
7

The first two courses of this specialization, Software Processes and Agile
Practices and Client Needs and Software Requirements, serve as
foundational pillars in learning Agile—they are the “legs” of the inukshuk that
depicts the structure of our specialization. This course, Agile Planning for
Software Products serves as the body of the inukshuk, and rests on the
“legs.” This means Agile Planning for Software Products brings together
many of the fundamentals of those two prior courses and builds on them.

In the introductory course, you learned that building better software involves three goals. These goals are:

1
2
3

 Have the right product
 Ensure it is done right
 Ensure it is managed right

When a project is managed right, it adopts suitable practices to organize the work of everyone involved and leads to clear next steps. This course focuses on ensuring a project is managed right.

1

Upon completion of this course, you should be able to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

 Understand the importance of planning.
 Explain the role uncertainty plays in affecting plans and task estimates.
 Break down tasks into appropriate sizes, and create a Work Breakdown Structure (WBS) for a
project.
 Explain the differences between estimates, targets, and commitments.
 Use different estimation techniques, including story points, velocity estimates and planning,
time boxing, and Gantt charts.
 Generate work estimates for software products using a variety of approaches, including bottom-
up, analogy, experts, and the estimate formula.
 Understand task dependencies, the different types of task dependencies, and how these affect
project planning.
 Create Critical Path Method (CPM) charts and Program Evaluation Review Technique (PERT)
charts.
 Create effective plans for software development on both iteration and release levels.
 Identify anti-patterns and types of risks that may affect projects.
 Assess and plan for project risks.

There are three key types of planning used in software projects. This course will cover all three of them. The types of planning are:

1
2
3

 Release planning
 Iteration planning
 Risk planning

There are four modules in this course.

Module 1 will cover:  Major uncertainties that projects need to resolve  How to break down work into manageable pieces  The difference between an estimate, a target, and a commitment

Module 2 will cover how to:  Estimate the size of a requirement using story points  Measure a development team’s productivity using velocity  Plan work using time boxing  Use a Gantt chart  Construct a release plan by mapping out the delivery of user stories over upcoming sprints

Module 3 will cover how to:  Estimate the time it will take to finish a task  Determine task dependencies  Use Critical Path Method (CPM) diagrams and Program Evaluation Review Technique (PERT) charts to plan work at the task level  Construct an iteration plan by mapping out tasks to be done within a sprint

Module 4 will cover:  Problems or risks that could cause a project to fail  Anti-patterns (situations with negative consequences for a project and its people)  Risk assessment and the level of action to take to address those risks  Constructing a risk plan by mapping out what to do should a risk occur

Introduction to Planning

Introduction to Planning

This course covers strategies and techniques for planning software projects within the Agile manifesto. This means the strategies and techniques covered must leave the project adaptable to change!

The key to planning software projects is breaking the project workload into small, manageable tasks. This involves describing and organizing tasks, and assigning them time and work estimates. Based on the identified tasks and their time and work estimates, an accurate schedule for the project can be made.

Software projects can be scheduled many ways on release and iteration levels. Risk planning must also be incorporated into creating schedules on both levels.

The release level refers to the stage where products delivered are ready for the market. Release planning is used to plan the project as a whole. Common release planning techniques include Gantt charts and release plans.

Iterations refer to smaller pieces of the project. They usually include a number of requirements that must be finished. A release is made of many iterations. Iteration planning is a technique that involves designing and developing the tasks that will be completed in a certain iteration of the project. Common iteration planning techniques include PERT charts, CPM charts, and iteration plans.

Both release planning and iteration planning must address potential risks that can arise in software development. Risk planning involves preparing for those risks in order to avoid negative repercussions in both creation and support of the product.

1

Upon completion of this module, you should be able to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

 Explain the importance of planning in a project.
 Describe the key terms within Software Project Management: task, role, schedule,
milestone, work product.
 Recognize and explain an Uncertainty Space (AUSP) diagram, and the concepts it
illustrates: means and ends uncertainty, and how they can evolve over a project.
 Define work breakdown structure.
 Recognize how the steps of project initiation, hardware/equipment acquisition,
development, testing, and implementation can be represented in a work breakdown
structure.
 Create a work breakdown structure based on an example.
 Identify the appropriate size for a task.
 Explain the terms: estimate, target, and commitment.
 Provide examples of estimates, targets, and commitments.
 Understand what a good estimate entails.

Important Terms

A number of important terms are used over this course that are related to planning. These should be well understood, before moving on to more complex discussions of planning software projects within Agile.

Term Definition

Task A task is a small, manageable step of a project that must be completed. Tasks are essential to a project—everything in a project can be broken down into tasks.

Role A role is a duty that a person takes on or plays in some relation to the product, as explained in the course Software Processes and Agile Planning. Examples of roles include programmer, tester, designer, client, and product manager.

Work product

1
2

A work product is an output produced by a task or process, as explained in the
course Software Processes and Agile Planning.

Schedule A schedule is created when the tasks of a project are mapped to a timeline.

Milestones Milestones^ refer to internal checkpoints used to measure progress. They are not time based, but event or action based. Milestones are most commonly used in linear and early iterative processes of a project, as explained in the course Software Processes and Agile Practices. In Agile, milestones are not generally used. Progress is instead measured by working software as opposed to events or actions. Releases and iterations tend to be time based as well, which do not fit with milestones.

These terms have certain dependencies on each other.

1
2
3
4
5
6
7
8

 Roles perform tasks. For example, programmers write code for selected features.
 Tasks not only create work products, but also might use them. This means that work
products might be dependent on one another. An output work product of a task might be
used as an input work product for a subsequent task. For example, the task of writing
tests produces the output work product of tests. These tests are then the input work
product for the task of executing tests.
 Tasks, once identified, can be used to create schedules. Work and time estimates can
be assigned to tasks, and project schedules can be built from these estimates.

Understanding dependencies is important. Dependencies influence how tasks need to be prioritized, and the consequential project schedules. For example, work products created in one task that are then used as an input for a different task must be created before they are needed in the project. Recognizing dependencies is therefore important for planning what to complete in each iteration of the project.

Previous Concepts

A brief review of previous concepts helps show how previous courses relate to planning.

Tasks, as described above, are an important part of planning a project, since everything in a project can be broken down into tasks. Tasks also played important roles in previous courses.

In the course Client Needs and Software Requirements, you learned about creating requirements. After the requirements have been created, they can be prioritized and broken down into developer tasks to be completed. These developer tasks can be more technology specific than requirements, which should generally be independent of technology. Developer tasks are commonly scheduled using an iteration plan, as you will learn in this course.

In the course Software Processes and Agile Practices, you learned about creating processes. Tasks are essential to creating processes, as they make up activities, and activities make up phases. Each phase therefore has specific tasks that must be completed.

Tasks are also important to Agile practices. Agile practices provide ways of organizing tasks and ensuring they are effectively completed. Iteration plans, as described above, are an Agile practice and used commonly in Scrum methodology. Scrum is a popular methodology for planning and organizing work on software products that follows the Agile philosophy.

Uncertainty Space

When beginning a project, there are many uncertainties. These uncertainties are often grouped in two types. A well-managed project must identify and address both types, simultaneously. The two types of uncertainty can be best understood through the questions:

1
2
3

 What are you creating in the
product?
 How will the product be developed?

The first question is associated with ends uncertainty. Ends uncertainty refers to uncertainty about what a product will do. The second question is associated with means uncertainty. Means uncertainty refers to uncertainty in how a product will be designed and developed.

Mike Cohn, one of the contributors to Scrum methodology, depicted the levels of uncertainty of a product as it proceeds from concept, through development, towards an operational state in an uncertainty space diagram. In such a diagram:

1
2

 The means uncertainty should go from high to low, along the x-axis
 The ends uncertainty should go from high to low, along the y-axis

1

DID YOU KNOW?

1
2
3
4
5
6
7
8

The grouping of project uncertainties into the two
types: means uncertainty and ends uncertainty
was first proposed by the project management
researcher, Alexander Laufer in 1997 in his book
Simultaneous Management. Laufer’s work is
noted for using real stories from successful
organizations, so his project management
theories are practice based.

This is demonstrated the diagram below.

At the beginning of a project, the uncertainty for both “what” is being created and “how” it will be created are very high, especially because requirements and methods will change over time. By the end of a project, however, what will be created and how it will be created should be clear, and uncertainties are low. At any point, if there is a high uncertainty for either axis, then some uncertainty must still be solved for the product.

Navigating Uncertainty Space Diagrams

There are many different ways to navigate through projects using the uncertainty space diagram:

1. Determine the “what” of a project first, then the “how.”
2. Determine “how” to develop a project, and then create it as you go.
3. Determine both the “what” and “how” of a project with as much balance between the two as possible.

The first way identifies what the project will create and then how to create it. Using this method, requirements are all determined first, and in great detail, before any plans for completing them are developed.

This method is likely following a waterfall process.

As illustrated above, this method leads to having low levels of ends uncertainty before the level of means uncertainty changes. Often, this change is significant when it happens.

This method of uncertainty planning is not very adaptable because requirements are established early and cannot change easily. It is therefore not in line with Agile methods.

The second way of navigating a project determines how to develop a product and then creates the product as the project moves along. Basically, the development team determines implementation solutions and makes the product up as they go.

This is ad hoc development, which involves little planning.

The chart above illustrates that second way leads to low levels of means uncertainty before the level of ends uncertainty changes. As in the previous method, the change in uncertainty is significant when it happens.

1
2
3

Ad Hoc Development often
refers to development that is
“made up as you go”.

This method of uncertainty planning can lead to wasted work if what is developed is not in line with client needs.

The third way of navigating a project is somewhere between the first two. Both the “how” and the “what” are accounted for around the same time, leading to balance between the two extremes. This is a more efficient means of navigating uncertainty than either of the previous two methods.

As demonstrated in the preceding graph, the levels of both ends uncertainty and means uncertainty lower at an equivalent rate.

However, development is not always this straightforward, as sometimes requirements are changed or added that will affect and create new uncertainties in both “what” the product will be and “how” it can be built.

A Final Note on Uncertainty Spaces

In most real-world cases, clients and the development team will define the majority of requirements for the project before planning begins. During this process, there might be less ends uncertainty than means uncertainty. However, once product development begins and the “how” is planned out more, the means uncertainty will lower.

As requirements are added or changed over the course of the project, there might be a slight fluctuation towards lower ends uncertainty, followed by lower means uncertainty. Development and solutions change as requirements change, so uncertainty will look more like the diagram below, instead of a straight line.

Both ends and means uncertainty should ultimately work their way towards being low. As changes or added requirements happen and any corresponding changes in development follow quickly, the project will stay adaptable and avoid wasted time and resources.

No matter the method of navigating uncertainty space, tasks are needed for the project to reach its end.

Work Breakdown Structure (WBS)

Creating a software product involves many tasks, including determining requirements and features, designing them, writing code, and testing. Often, other kinds of work are also involved, such as marketing the product and arranging technical support and operations. All of these require planning—the development team cannot simply begin developing the project without any plans. The key to being able to plan a software project is to break it down into manageable pieces.

In project management, the technique of work breakdown structure (WBS) creates a visual representation of the process of breaking down large project work products into smaller task work products. Tasks should be broken down until each is small and clear enough to be assigned to a single person. WBS is therefore also a hierarchical representation of project tasks and deliverables. It can take on the form of a list or other visual representation. Dates and order of execution are not included in a WBS.

Creating a work breakdown structure is a good first step in putting together a detailed plan for the project. It is important to be balanced in breaking down tasks within a work breakdown structure. Although tasks should be broken down until they are manageable, if they are too small, this will lead to micromanagement.

1

Instructor’s Note:

1
2
3
4
5
6
7

A work breakdown structure is
similar to concepts you learned in
the course Software Processes
and Agile Practices. For
example, a process is broken
down into activities, which in turn
are broken down into tasks.

WBS can be organized functionally or by phase. Common steps included are:

1
2
3
4
5
6
7
8
9

 Project initiation (when a new project is started and objectives, scope, purpose, and
products are decided)
 Hardware and equipment acquisition (determining what hardware or equipment is
needed to create the product, and obtaining those)
 Development (designing and creating the product)
 Testing (determining the performance and reliability of the product to identify and fix
problems)
 Implementation (when the product is executed for outsiders of the project to be able to
access and use)

These steps should be found at the highest level of the WBS (underneath the top level, which should be the final product or project), and then broken down appropriately in subsequent levels. A good resource for learning more about WBS levels is the Project Management Body of Knowledge Guide (PMBOK) (see Course Resources).

In general, final tasks identified in the work breakdown structure should be independent and unique of other tasks.

Example Work Breakdown Structure

Below is a graphic that illustrates how a work breakdown structure might look. In this example, the project is to create a News Application.

1

TIP:

1
2
3
4
5
6
7

The acronym SMART is sometimes applied to determine if a task or work product is a good size. The
letters in SMART can stand for many things, but it generally means that a task should be:
 Specific (the task should be clear and should not overlap with other tasks)
 Measurable (the task should have a definite way of being marked as finished or done)
 Achievable (one person should be able to do the task)
 Relevant (the task should be within scope of the project)
 Time boxed (the task can fit within a certain time frame)

1
2

Some guides to creating WBS suggest other more specific rules of thumb to help know if tasks are
manageable, including that the lowest level should take no more than 80 work hours to finish.

1
2
3

Another important tip is to remember to keep tasks within the scope of the project! This ties into the
100% rule often associated with WBS, which states that 100% of the work defined by the project
scope should be included in the WBS.

The product is the highest level of the WBS, and it is subsequently broken down into smaller tasks in a hierarchical tree. The level under the highest shows steps similar to phases, including programming and documentation.

Looking more closely at the “Programming” branch and its sub-branches, “Links/Buttons,” “Layout,” and “Live Embedded Widgets,” you can see that each of these items can be broken up into smaller tasks.

For example, all three need a source code. Any work products will also have associated tasks in the form of creating unit tests and acceptance tests.

Unit tests test the low-level functionality of source code; they should be written before source code is. For the sub-branch “Links,” a unit test could determine if links are working appropriately, for example. Acceptance tests, on the other hand, verify the application as a whole. In this same sub-branch, an acceptance test could test the interface to make sure that all the links are functional and correct, for example.

Designing the layout is another work product that should be listed, as well as any acceptance tests associated with the design that make sure the layout is compatible and functional on multiple devices.

These smaller tasks of creating designs and writing tests are good-sized work products. They are much more manageable than a large task such as “create a news application” would be. They are also in scope, unlike a task such as “create entire source code for reader chat room.” A task like the last one should be not be included in a work breakdown structure, because it is too large to tackle easily, and can easily result in missed smaller tasks and nuances.

Creating a Work Breakdown Structure

Large projects may have hundreds or thousands of tasks, and using a simple WBS tree chart similar to our example can quickly become unwieldy. Many other tools are available to help create work breakdown structures on larger scales, including Microsoft Excel and Microsoft Project. Both are better suited for large-scale projects.

Work breakdown structures are also not limited to product management concerns surrounding the Design and Implementation phase. They might also include Specification phase activities, Verification and Validation phase activities, promotion, arranging technical support, gathering analytics, setting up servers, etc.

Uses of Work Breakdown Structures

Work breakdown structures can be used many ways.

The most common use of a WBS is to determine tasks for the project based on the work products displayed. Small, manageable work products can easily be turned into small, manageable tasks. If the work product is “Source Code” for “Links,” as in the example above, then the task “Write source code for Links” can be easily created. This is very helpful in the early stages of planning a project because it considers the entire project, and tasks can then be used to create schedules.

In a similar vein, work breakdown structures can be used to help assess how long it will take a development team to complete a project. It is easier to estimate how long small tasks will take to finish, and then to add those times together to determine a project estimate, than to estimate the project as a whole.

WBS may also be used to determine potential risks the project will encounter. Once work products have been identified through a WBS, risks can be determined for each of those work

products. This is much more efficient than trying to determine risks from looking at the product as a whole.

Finally, a work breakdown structure can also be used to demonstrate a product to a client in a way that allows the client to look at features individually.

Estimates, Targets, and Commitments

The terms estimate, target, and commitment are often used interchangeably in project management. But, in fact, all three of these terms mean something different.

Estimates

An estimate is a guess of the time it will take the development team or worker to complete a task. A good estimate is usually based on a well-formed task, which adheres to SMART. They are also usually determined by the developers who will work on the task.

An estimate should be as accurate as possible, and it is often based on data, like the amount of time it took to accomplish a similar task. However, because a precise number of hours or days is probably inaccurate, estimates are usually ranges.

It is important to understand that although estimates are sometimes presented as ranges, they are not negotiable. This means that an estimate should only take into account previous work. It should not include padded or extra time or be affected by what stakeholders or managers want the estimate to be.

Other issues that might affect the ability to make a good estimation include:

1
2
3

 Lack of developer experience with similar tasks
 Too much attention to detail on tasks leading to over-estimates
 Not enough information available on the task to create an accurate estimate

This last issue, lack of information leading to difficulties in creating a time estimate relates to the Cone of Uncertainty Principle. This principle suggests that time estimates for features are less accurate the further into the future those features are intended to be developed. For example, estimating development is more difficult at the beginning of the project, when ideas are still being passed around, than towards the end of the project, closer to actual development stages.

The Cone of Uncertainty Principle is explored in larger detail in the lesson Estimating Task Time in Module 3: Planning of this course. It was also touched upon in the previous course, Client Needs and Software Requirements. Developers may also express reluctance in determining an estimate if they fear not being able to meet an estimate. This could be a sign of larger organizational difficulties within the project. Clients may assume that estimates are targets or commitments, which could be problematic. Clear discussions about estimates, targets, and commitments between the development team and clients helps address this issue.

Approaches for creating an estimate include:

1
2
3
4

 Bottom-up
 Analogy
 Experts
 Using an estimate formula

More information on how to use these approaches can be found in the lesson Estimating Task Time of Module 3: Planning in this course.

Targets

A target is a specific point in the schedule for the project or part of the project to meet. It is almost an ideal deadline, and is usually set externally to the development team. Like estimates, targets are not negotiated. Once a target has been decided, it must be adhered to for product success and client satisfaction. In fact, targets are often contractual and can be used in arranging product promotions.

Examples of targets are ends of a sprint or the release date of a product.

Commitments

Commitments are what you agree to deliver. Commitments are where negotiations can happen. Based on both estimates and targets, a commitment can be negotiated. A good question to ask when determining commitments is, “How do I compromise on what the development team will commit to doing, based on their estimates and the time constraints (of the project)?”

In order to determine a commitment, best practice suggests that estimates should be discussed with the development team first, so accurate numbers can be determined. There should also be discussions with the client in order to determine target dates. Then, based on these discussions, commitments can be determined with both the development team and the client.

Estimate, Target, and Commitment Example

To better understand estimates, targets, and commitments, examining an example is beneficial. A theoretical project may be estimated by the development team to need 1,000 hours of work, based on the requirements the client has expressed. This is an estimate. The client, however, may want the project finished within 600 hours. This is a target. After negotiating, the client and development team may adjust the scope of the project so it seems to include about 500 hours of work. This is a commitment. The project may take more or less time to finish than the commitment, and that actual time can be used as data for future estimates.

As you can see in this example, although both estimates and targets are non-negotiable once set, it is still possible to negotiate what you commit to for the scope of the project.

It is common for estimates to be automatically converted into commitments and targets, but this is a bad practice. Drawing on the previous example, if a project is estimated to take 1,000 hours

of work, often clients will automatically assume that this is a commitment of 1,000 hours. This often leads to the temptation of inflating estimates, also a bad practice.

It is therefore important that estimates, targets, and commitments are made clear and separate for both the client and the development team in their discussions. If this can be done, it is more likely that the project and its target dates can run as planned, without the scope becoming too large, as it ensures that target dates can actually be met. Again, drawing from the above example, understanding that 1,000 hours is an estimate, and the target is 600 hours helped create a commitment of 500 hours. This commitment helped narrow the scope of the project to stay within the target.

Estimation

Story Points

As explored in the previous module, good estimates are based on good reasoning. For example, the amount of time it took to develop and finish a task in the past could be the basis for an estimate on the amount of time it would take to complete a similar task in the future.

In an ideal world, past performance would be the only thing that influenced an estimate. In reality, however, developers often feel when they give an estimate that they should “pad” their work—in other words, some extra time should be added—in case their initial estimate is mistaken for a commitment and is wrong. In fact, it is very difficult to make a reliable estimate, especially if the task is far in the future (see the Cone of Uncertainty theory discussed in Module 3 of this course).

Estimates are easily mistaken for commitments because they are both measured in units of time. It is easy to jump to the conclusion that the time suggested in an estimate can be simply converted into work hours. However, this isn’t very accurate, and should be avoided.

Story points were developed as an alternate system for estimates. Instead of estimating how much time work will take to finish, story points are an assigned value that look at how long it will take to finish a piece of work in relation to other pieces of work. Story points are therefore relative measurements, and unitless, unlike time estimates. In time estimates, hours or days are the units used, whereas in story points, the points are not representative of any particular measurement. This is explained more in How to Use Story Points, below.

How To Use Story Points

Story points build on concepts explored in the course Agile Requirements for Software Products, such as user stories. User stories are short, simple, uniformly formatted descriptions of a feature told from the perspective of the person who desires the feature. User stories generally take on the format:

1

Upon completion of this module, you should be able to:

1
2
3
4
5
6
7
8
9

 Define and create a story point.
 Identify different ways of sizing a task.
 Explain what velocity is, how to calculate a velocity estimate, what factors influence velocity,
and what makes velocity stable.
 Explain the concept of done, and how a story is only counted towards velocity if it is done.
 Define time boxing and its relation to Scrum.
 Define release.
 Explain and create a Gantt Chart.
 Explain and create a release plan.

“As a ‘ _____ ,’ I want to ‘ _____ ,’ so that ‘ _____ .’

Another concept from the same course that is relevant to story points is the Scrum product backlog, which is a set or list of software features that the software product manager and development team plan to develop for a product over the course of a project.

In order to use story points, a relatively easy to estimate product requirement or user story should first be selected from the product backlog and assigned an integer value. This value is a story point. Using this basis, story points are then assigned to the rest of the user stories. For example, if a task twice as big as the base task is found, it will be assigned approximately twice the number of story points.

After this is done, you will be left with a list of user stories whose work estimates are all relative to each other, as they are all based on the same point system. This prevents accidentally committing to a time period, but instead just determines how large each user story actually is. This is much more in tune with the true purpose of estimates.

The total number of story points can be added up for all of the user stories in the project, giving some idea of how large the project will be.

It is extremely important, however, to remember not to treat story points like hours, or they offer no advantages. For example, it is easy for a developer to just “translate” hours into user points. In general, story points should not be very precise; instead they should stay relative. This means that large numbers such as 10, 50, or 100 are bad as base numbers because they are prone to be viewed as percentage points.

A good practice is to use story point values that are fixed. This helps avoid story points from simply becoming interpreted as hours.

1

TIP

1
2
3

A good way to make sure story points stay fixed and relative is to use the Fibonacci sequence. The
Fibonacci sequence is a sequence where any individual number is the sum of the two numbers that
precede it. The sequence runs like: 1, 1, 2, 3, 5, 8, 13, 21, etc.

1
2
3
4

If the Fibonacci sequence is used, story points should be restricted to only those numbers for
estimates. This means that if an estimate falls between two numbers in the sequence, you must round
up the nearest available number. For example, if you have a user story that is approximately twice as
much work as one with the assigned value of 2, you should assign it the number 5, not 4.

1
2
3

Using the Fibonacci sequence for story points keeps estimates tidy and avoids making large estimates
unnecessarily precise. It also accounts for uncertainty this way. As it is not a direct correlation with
hours, using the Fibonacci sequence also prevents unintended commitments from being formed.

Advantages of Story Points

Aside from the face that using story points as estimates helps to not create unintended commitments, story points offer other advantages. Creating estimates using story points tend to lead to more accurate estimates. Humans in general tend to be bad at making exact estimates from scratch, but a method of estimating based on relative sizes makes it easier.

Imagine trying to estimate the size of a building. Your gut feeling might tell you that the building is sixty metres tall. Unless you actually measured the building, you would have no idea of how tall the building exactly is. So, your estimate could be very inaccurate. If you were to use a system similar to story points, however, you would compare that building to another, smaller building nearby. If you assigned the small building a value of 1, and you believe the taller building to be about three times taller, then it would have a value of 3. It is must easier to estimate this way than to just use a best guess.

Using story points for estimations is also potentially less stressful for developers, because nothing is exact. This means it is harder to “go over the estimate” like one could go over a time “deadline.”

Limitations of Story Points

Although story points offer many advantages, they are not a widely accepted practice, even for those who use Agile methods and Scrum. This is because there are several notable limitations to story points too.

One way in which story points can be difficult is that they require a shift in thought from time to points. As a result, developers might be tempted to treat points like hours. This limitation could be resolved through increased exposure and practice with using story points.

Estimates are always difficult to make accurately, whether with hours or story points. Although using relative sizes generally results in more accurate estimates than using exact numbers, this is still open to mistakes.

Story points are open to limitations on large teams as well. Sometimes, story points are inflated to give the appearance of productivity. This practice is acceptable if it’s applied consistently (e.g., if the inflation of the numbers is the same across the project). If inflation of numbers starts halfway through the project due to the introduction of new features or pressures, then story points will lose value and become less useful for estimation. The important thing about story points is consistency.

Velocity Estimates

Velocity is a measurement of the work that can be taken on and finished over the length of a sprint. Velocity is represented as the number of story points completed over a given period of

1
2
3
4
5
6
7

As an example of how bad humans
are at accurate estimation, consider
the vertical-horizontal illusion. It can
be difficult to tell if a horizontal line
and a vertical line are the same
length, even if both are visible at the
same time.

time. An example of a velocity could be 15 story points per sprint. Velocity is helpful because it serves as a means of:

1
2
3

 Estimating the effort the development team can achieve throughout the project
 Estimating effort that can be achieved on future work
 Indirectly tracking the team’s productivity

1
2
3
4
5
6
7

Velocity can be measured as the number of user stories
or work items delivered over a sprint. However, using user
stories in velocity can be problematic, because not all
user stories in a project are the same size. Velocity can
also be measured through the number of story points
completed over a sprint. Story points make for more
accurate measurements.

A project should use either user stories or story points in velocity and consistently use the same measurement. Mixing the two would be confusing, as they are interpreted in different ways. In this course, we will focus on using story points over sprints as our productivity metric.

For story points to count towards velocity, they must be finished completely. Partially finished tasks do not count towards velocity. Using story points that are considered completely “done” in velocity estimates is very important.

How can it be determined if a user story is “done”? In Scrum and Agile methods, a user story is not done when the functionality has only been coded. A user story must also pass both unit tests and acceptance tests and then must be documented before it is considered “done.” The additional completion of testing and documentation to coding is sometimes referred to as “done done” in the field.

Velocity-Driven Development

Velocity serves as the foundation of velocity-driven development. This kind of project development happens when the velocity of previous sprints is used as a basis for planning other sprints in the project. For example, if the three previous sprints of a project had a velocity of 15 points per sprint, then this can be used to plan the next sprint. User stories can be selected based on their story points until the total number of points projected to be finished in a sprint is 15 points or less. A development team knows better how much work they can get done if they can use past data to help predict what might be done in the next sprint.

Velocity-driven development requires a certain amount of stability in past velocity. At the beginning of a project, velocity may not yet be steady as there are still a certain amount of inaccuracies, and it may take a few sprints for it to even out. In order to help calculate stable velocities, it is important to be strict about counting story points only when they are done. For example, if two stories worth 3 points each are complete at the end of the sprint, and a third story worth 4 points still needs testing, this third story should not be counted. The sprint total should be 6, and not 10. This practice also helps to force or to encourage closure to stories rather than to constantly start new ones.

When estimating velocity, will find yourself in one of two places:

1
2
3
4
5
6
7

In this course, a sprint is the same
thing as an iteration – they are both
short, iterative, and incremental time
periods. In other words, both are
ways to time-box work in small
chunks. Time boxing is explored
more in the next lesson.

1
2
3

 The beginning of a project, when it is difficult to estimate velocity because no prior work
has happened on which estimates can be based, or
 The middle of a project, when it is easier to make estimates based on prior work.

As in estimation, in cases where no prior work can be drawn on at the beginning of a project, it is possible to:

1
2
3

 Consult experts who may have worked on similar projects previously and who might be
able to offer insights, or
 Draw on the team’s own prior experience with similar projects to make estimates.

Previous data can be used to determine estimates through a variety of techniques, including but not limited to:

1
2
3
4

 Linear extrapolation (extending graphed data beyond the known data in a straight line
based on how previous data has behaved),
 Averaging the velocity of the three previous sprints, and
 Using the minimum velocity of the three previous sprints.

Some Considerations in Using Velocity Estimates

There is a little bit of controversy over using velocity estimates that are important to acknowledge. Velocity estimates are not necessarily accurate, because velocity is variable. This reinforces the importance of only counting stories that are “done” by the end of the sprint. This helps counteract variability. It is also important to remember that velocity is derived from estimates, so it should still be seen as an estimate.

Velocity still offers many advantages, as it shares the advantages offered by story points. Velocity is also considered better for long-term tracking, especially as velocities become more consistent over the course of a project. And although velocity is not considered an ideal means of tracking the individual productivity of team member, it is considered a good tool for decision- making.

For more information on some of the considerations on using velocity estimates, see Michael Cohn’s “Why I Prefer Commitment-Driven Planning” in the Course Resources.

Time Boxing

Time boxing is creating a restricted time period in which something is to be built, or for certain tasks to be finished in. The key to time boxing is the strict time limit—the event must stay within a predetermined timeframe.

Time boxing is a popular organizational method, as it allows software teams to compartmentalize work they have planned. Good time boxing also plans out the work at the beginning of a time period and leaves room for reflection on the progress of the project. Time boxing is particularly important to Scrum.

Scrum sprints, usually between two to four weeks long, a type of time box. They consist of a relatively small amount of work that is restricted to a relatively short development time. Scrum sprints include planning and review periods before and after work is done.

Time boxes are created when a time period is set in the project during which a certain amount of work will be planned, accomplished, and reviewed. Sprints and iterations are a kind of time box. Time boxing helps keep a project on track at a regular, sustainable pace because it divides the project into manageable chunks. The goals and milestones generated by time boxing helps development stay within scope and keep things on schedule. As work is planned over small doses of time, determining upcoming targets and their time periods becomes easier. It makes a project much more efficient than working with an uncertain schedule.

Developers should beware of putting too many tasks into a time box, or they cannot be finished. Velocity helps inform how much work can be completed in one time period, as previous work informs new estimates.

The organizational ability time boxing offers projects is sustainable. Further, it allows the team to learn from work at regular intervals, because of the built-in review period. It also allows the development team to see how work will be divided throughout the project.

A project can be released in stages, at the end of each time box. This is because at the end of each time box, working software should be created, which can be released as a product. All work in a time box must be finished. Time boxing thus ensures that a tangible product is available at the end of a project, even if resources are lost along the way. This kind of progress also improves team morale.

Gantt Charts

Gantt charts are simple tools for visualizing project plans or schedules. They are a kind of cascading horizontal bar chart. Gantt charts can also be used to visualize task dependencies, the length of tasks, and deadlines.

Gantt charts plot tasks on the left-hand side of the chart against dates, which are displayed at the top of the chart. Each task is listed separately, one by one, and given its own horizontal bar. The first scheduled task is at the top of the chart, and progressive tasks are displayed underneath it. Each task’s bar represents the duration of that task from its start date to its finish date. Once all tasks are laid out on a Gantt chart, you can see when each individual task is scheduled to begin and end.

Below, is a rough template of what a Gantt chart looks like. In a real example, the tasks would be given descriptive names, and there may be several more tasks.

Gantt charts are useful in both Agile and non-Agile projects. Because sequential tasks can be displayed in a Gantt chart, non-Agile processes, such as the Waterfall process, can make productive use of Gantt charts. In Agile environments, Gantt charts are also useful.

In order to use Gantt charts successfully with Agile methods:

1
2
3
4
5

 Additional context should be provided to tasks (such as identifying if there are task
dependencies)
 Parts of the chart can be sectioned off as sprints
 The charts must be used with an understanding of flexibility and adaptation to project
needs (in other words, the chart could change as the project unfolds)

As detailed on the preceding page, Gantt charts allow the team to visualize when a project will be finished, when tasks are to be worked on, the length of those tasks, and potential project dependencies. Project dependencies and the different types of dependencies that can exist in projects are described more in the Task Dependencies lesson of the next module, but a brief outline of representing task dependencies in Gantt charts follows below.

In order to display task dependencies on a Gantt chart, first, a project backlog of tasks should be created and prioritized. Tasks that are dependent on the completion of other tasks should be identified on this list.

When a Gantt chart is produced based off of tasks and their time estimates, tasks that are dependent on others should be identified through the use of an arrow, going from a task towards the one that depends on it. In general, however, other planning techniques such as Critical Path Method (CPM) charts and Program Evaluation Review Technique (PERT) charts are favoured for demonstrating task dependencies. More information on how to visually represent task dependencies can be found in Module 3: Planning of this course.

1

31-Dec 10-Jan 20-Jan 30-Jan 09-Feb 19-Feb 01-Mar11-Mar

1

Task 6

1

Task 5

1

Task 4

1

Task 3

1

Task 2

1

Task 1

Example Gantt Chart

In the example below, Task 5 is dependent on Task 4, as represented by the flowing arrow.

Gantt charts can be used on both the iteration level or the release level. On the iteration level, Gantt charts help provide insight by outlining tasks that should be completed within a few days in a current sprint. On the release level, Gantt charts represent user stories instead of tasks, so it can provide information on user stories over an upcoming series of sprints.

Release Plans

Planning is a process that can occur on both the iteration level and the release level. This is known as two-level planning. As explained in the first module of this course, iteration planning involves dealing with tasks on a detailed level, while release planning deals with broader level user stories. Both levels of planning rely on time boxing in the form of sprints to organize either the tasks or user stories.

Iteration plans are generated at the beginning of a sprint in Scrum and Agile methods during the scheduled planning event. The iteration plan plans out the developer tasks to be completed during that particular sprint. Tasks tend to be actionable items, or items that a developer can complete. A user story consists of many tasks. Tasks are then self-assigned by the developers on the team before the work even begins. At the end of the sprint, working software should be created, which can then be shown to the client during the review event. Iteration plans are explored in more detail in the next module.

1

31-Dec 10-Jan 20-Jan 30-Jan 09-Feb 19-Feb 01-Mar11-Mar

1

Task 6

1

Task 5

1

Task 4

1

Task 3

1

Task 2

1

Task 1

Example Gantt Chart with Task

Dependency

1
2
3
4
5

Many different tools exist to help create Gantt charts, including:
 Microsoft Excel
 Microsoft Powerpoint
 Gantt Project, an open-source Gantt chart creator (http://www.ganttproject.biz/)
 Many other subscription projects

Release plans, on the other hand, are used to plan a few sprints at a time by determining which user stories from the project backlog should be completed and released in which sprint. User stories are chosen by priority. Generally, release planning occurs before any sprint is started—therefore, it occurs before iteration planning. User stories in release plans should be distributed logically and evenly across sprints; otherwise, they may be finished in a disorganized or haphazard manner, which may cause issue with task dependencies.

A prioritized project backlog, as described in the Client Needs and Software Requirements course is therefore key to release plans. User stories can be planned in a release plan from the top priority down:

1. “Must do” user stories (top priority)
2. “Should do” user stories (medium priority)
3. “Could do” user stories (low priority)

User stories are distributed across sprints pulling from these priorities, until each sprint is filled with an appropriate amount of work.

The number of user stories to assign during a sprint can be determined through many ways, including:

1
2
3
4

 Prior experience can help inform how many user stories can be finished in a sprint
 Data such as velocity estimates and story points can be used. Velocity can inform how
many story points might be able to be finished in a sprint. User stories can be added
until their story points add up to more than the projected limit.

Release planning should give an accurate projection of what the product will look like at the end of an upcoming series of sprints. A good release plan helps with client expectations and increases developer morale because tangible results are planned and expected.

1

TIP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

In addition to creating release
plans that cover a few sprints,
the product manager should
also create a long-term “road
map” plan, which covers the
majority of the project and its
user stories, if not the entire
project. This helps give an idea
of how the project will
progress.

Planning

Estimating Task Time

Cone of Uncertainty Principle

Before exploring the different approaches that can be used to estimate task time, it is important to understand the Cone of Uncertainty Principle, which informs the accuracy of an estimate.

The Cone of Uncertainty Principle works off of the fact that uncertainty is high at the beginning of a project and becomes lower as the project progresses, as discussed in the lesson Uncertainty Space in Module 1: Introduction to Planning of this course and in the course Client Needs and Software Requirements. The principle suggests that estimates made when uncertainty is high will be inaccurate. It also suggests conversely that as the project progresses, uncertainty is reduced because the requirements and development pace become clearer and, in turn, estimates will become more accurate.

The Cone of Uncertainty can be illustrated graphically.

1

Upon completion of this module, you should be able to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

 Describe what makes a good estimate.
 Explain issues that may affect estimation, including the concept of the Cone of Uncertainty.
 Explain different approaches for creating estimates, such as bottom-up, analogy, and
experts.
 Be able to calculate task estimation time using the estimation formula.
 Understand task dependencies and the different types of task dependencies: start-start,
start-finish, finish-start, and finish-finish.
 Explain a critical path method (CPM) chart.
 Explain the concept of slack.
 Explain and create a PERT chart.
 Explain the differences between a CPM chart and a PERT chart.
 Explain and create an iteration plan.
 Understand that planning is self-assigned work done by developers; it is not assigned by
clients.

1
2

Image adapted from Software Estimation: Demystifying the Black Art (2006)
by Steven C. McConnell. Used with Permission.

On this graph, the progression of the project over time is represented on the x-axis. Variability is represented on the y-axis. Variability refers to the factors or the extent by which an estimate could vary. The larger the factor, the greater the variability. Each number on the y-axis therefore represents a factor of variability, and the x represents the mathematical operation of multiplication.

The graph illustrates how at the beginning of a project, there is high variability and towards the end of the project, the variability significantly lowers. This creates a cone shape, which is where the Cone of Uncertainty principle gets its name.

The Cone of Uncertainty graph is illustrated below, with important points in the project included. This helps illustrate how variation changes at different points in the project over time.

The important project points are as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

 The Initial Product Definition – when the idea for the product is first formed. At this
stage, variability is high (between the approximate factor of 3 and 0.375), and estimates
will need a large range.
 The Requirements Elicitation activity – when the needs of the product and features
have been identified. At this stage, variation is smaller (between approximately 2 and
0.5), and estimate ranges will be smaller too.
 Formulating Potential Approaches – when the methods used to do the project are
chosen. At this stage, variation (between the approximate factor of 1.25 and 0.8) and
estimate ranges become even smaller.
 The Architecture Design and Detailed Design stages, when information is known on
how and what will be created in the end product. At these stages, the estimate becomes
even more reliable as variation decreases (variation becomes closer and closer to a
factor of 1).

Estimate ranges for the project can be made using the variability as illustrated in this graph. In order to do this, the estimate should be multiplied by its corresponding factor variability for where you are in the project. These will make the top and bottom numbers of the estimate range. For example, if a task is estimated to take 6 hours in the Requirements Elicitation Stage, this means it has a variability of 2 and 0.5 on the y-axis.

1
2

2 x 6 = 12
0.5 x 6 = 3

This gives an estimate range of 3 to 12 hours. As you can see, at this stage, there is still a great deal of uncertainty.

Using variability to create estimate ranges helps ensure a more accurate range. Estimates should also be continually revised as the project moves through the Cone.

Creating Time Estimates

There are many approaches to creating time estimates. All of these approaches, however, should be based on some sort of data. Remember also that estimates are non-negotiable figures.

This lesson will present several approaches that can be used to create time estimates:

1
2
3
4

 Bottom-up
 Analogy
 Experts
 Using an 3 - Point Estimate Formula

Bottom-Up

Bottom-up is a technique for creating a time estimate that involves breaking apart a project into small, manageable tasks, as done in a Work Breakdown Structure (WBS). Once the tasks have been broken up, they are much easier to estimate. If all the small tasks are given estimates, these estimates can then be added together to create an estimate for the full project.

Below is an example of a Work Breakdown Structure (WBS), where each of the tasks has been represented as hours. Once all the hours are added up, we can see how long each section of the structure is estimated to take and how long the entire project is estimated to take.

1
2
3

TIP: If it is necessary to create an estimate quickly,
usually the bottom-up technique is the best to use,
if enough information is available.

Note that even small tasks, which are easier to estimate, can be difficult to estimate accurately if there is not enough data to base that estimate on. This technique therefore works well when combined with another, especially in cases where there is not enough data to create an accurate estimate.

Analogy

Analogy is a technique for creating a time estimate that works by comparing the current task or project with a similar experience. If a similar task or project was accomplished in the past with similar scope and costs, then it can be a good basis for estimating the current project.

This technique should be used with some caution, as it can only work if the same team has worked on a similar project. This means the work, process, technologies, and team members have to be the same or similar to the current project to be a meaningful basis of data.

Experts

Time estimates can also be generated through experts. This technique works by converging estimates made from multiple estimators—generally developers who have prior experience with

1
2
3
4
5
6

This technique assumes that none of
the tasks in the Work Breakdown
Structure (WBS) can be performed
simultaneously, but instead that each
task must be completed before another
can start.

the kind of work at hand. This technique is normally used in cases where the development team has limited experience with the work required for the project.

This technique can be costly, as it requires several estimators to look at the project. It can, however, also be very accurate.

The PERT 3 Point Estimate Formula

A useful tool used to estimate task time more accurately is the three-point estimation. This is known as the PERT 3 Point Estimate Formula, and it can create a range estimate. The formula is based on three values, which can be determined through prior experience or best- guesses:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

 Most Probable Time (Tm) is the most likely estimate of the time it would take for the
task to finish. This estimate operates under the assumption that the project or the task
may encounter normal problems. Any of the bottom-up, analogy, or experts techniques
can be used to generate this estimate.
 Optimistic Time (To) is the best-case scenario estimate. It assumes that everything will
go right over the course of the project or the task and that the development team will
work efficiently. It is therefore the least amount of time the task or project could be
completed in.
 Pessimistic Time (Tp) is the worst-case scenario estimate. It assumes everything or
almost everything that could go wrong over the course of the project or task will. It is
therefore the maximum amount of time the task or project could be completed in.

Using these three variables, the Expected Time (Te) can be calculated for the task. The Expected Time is a weighted average that can be calculated with this formula:

This formula places emphasis on the Most Probable Time that is multiplied by 4, giving it more weight in the formula. It is then averaged with the Optimistic Time and the Pessimistic Time.

The Expected Time is usually represented as a range. In order to create a range, we need some information about the probability that the estimate is correct. This is done by calculating the deviations of the Expected Time.

1
2

Te = (To+4Tm+Tp)
6

1
2
3
4

TIP: It is important to remember that all projects will have unique issues that arise over the course of
the work, regardless of how similar it is to other projects. This means that any of the bottom-up,
analogy, or experts techniques should be made with the understanding that these unique issues,
which could not have been otherwise accounted for, may affect estimates.

Deviations are represented by the Greek letter sigma (σ). Standard deviations represent how measurements can be spread out from the expected value. These are based on normal distribution plots or bell curves, which work based on percentages.

A normal distribution assumes that numbers are spread out in a certain way from standard deviation (in this case, the Expected Time), and that those values within one deviation (σ) of the standard deviation are 68.3% likely to be accurate. Within two deviations (2σ), there is a 95.5% chance the number is accurate. These numbers are drawn from bell curve and statistic theory.

To calculate deviation, the following formula is used:

1
2

σ = (Tp-To)
6

The smaller the difference between the Optimistic Time and the Pessimistic Time, the smaller the deviation will be. Once the deviation has been calculated, it can be subtracted from the Estimated Time (Te) to get the low number of the range. The deviation can also be added to the Estimated Time (Te) to get the high number of the range.

If one deviation (σ) is used to create a range, we can assume that the range is 68.3% likely to be accurate. However, if it is more important for the project to have an accurate estimate than a smaller one, you can double the deviation (2σ) by multiplying it by 2, to reach 95.5% accuracy. More information on the estimate formula can be found in supplementary readings found in the Course Resources. A worksheet is also available to help with practice using the formula.

1
2

Sometimes a triangular distribution is also calculated using the same three variables, and the formula
is:

1
2

Te = (To+Tm+Tp)
3

1
2
3

This formula places less emphasis on the most likely scenario, as it not weighted higher by being
multiplied by 4. Using the variable in the example below, this equation gives us an estimate of 10 days
to finish the task, instead of 9.

1
2
3
4
5
6
7
8

Although deviations are used to create time
ranges in the course of planning, deviations
can also be expressed using the ± (plus or
minus) symbol after the Estimated Time.
For example, if the Estimated Time is 12
hours, and the deviation is 2, this could be
expressed as 10-14 hours, or in some
cases, 12 hours ± 2.

Estimate Formula Example

Understanding the estimate formula can be easier through the use of an example. Using the hypothetical numbers for a task:

To = 5 days Tm = 8 days Tp = 17 days

We can calculate the answers to the estimate equation:

1
2

Te = (5+ (4x8) +17)
6

1
2

Te = (5+32+17)
6

1
2

Te = (54)
6

1

Te = 9 days

In this example, standard deviation would be:

1
2

σ = (17-5)
6

1
2

σ = (12)
6

1

σ = 2

So, the estimation for this task would be 9 days ± 2 (a plus or minus deviation of 2 days). This would likely be expressed as an estimate of 7 to 11 days to finish the task.

Task Dependencies

Task dependencies, as briefly discussed in the Software Processes and Agile Practices course, and the lesson Introduction to Planning at the beginning of this course, refer to those situations where one task is dependent on another task or set of tasks in some way.

Task dependencies are very important to planning and scheduling, because they shape the order in which tasks must be done.

1
2
3
4

Sometimes the numbers created through using the estimate formula will not be whole numbers (in
other words, they may have numbers after the decimal). In these cases, it is important to round the
estimate up to the next highest number. For example, if the formula yields the number 6.9, it should
be rounded up to 7. Similarly, if it yields the number 5.1, it should be rounded up to 6.

There are four types of dependencies. They differ in how the second depends on the first:

1
2
3
4

 Start-start dependency
 Start-finish dependency
 Finish-start dependency
 Finish-finish dependency

Start-Start Dependency

1
2
3
4
5
6
7

Start-start dependencies refer to those dependencies where the first
task must start before the second task can start. When tasks finish in
this dependency is not important.
Start-start dependencies are visually represented as follows, with an
arrow going from the beginning of Task A to the beginning of Task B.
The two tasks are shown more or less in parallel. Task B depends on
Task A starting.

This method of representation can be used in any number of visual representations, including Gantt charts and PERT charts.

An example of a start-start dependency could be working on a project and creating a glossary. The project must be started before a glossary can start. These two tasks can be worked on simultaneously, however, and it does not matter which one is finished first.

Start-Finish Dependency

1
2
3
4
5
6

Start-finish dependencies refer to dependencies where the first
task must begin before the second task can finish. These
dependencies generally involve some kind of overlapping handover.
In start-finish dependencies, the start of the second task is not
important. In other words, the first task can start before or after the
second task starts.

Start-finish dependencies are visually represented as follows, with an arrow going from the beginning of Task A towards the end of Task B. Both tasks are shown more or less in parallel. Task A must start before Task B finishes.

This method of representation can be used in any number of visual representations, including Gantt charts, and PERT charts.

An example of a start-finish dependency could be planning the next sprint during the current sprint being worked on. This allows the development team to begin working immediately upon starting the next sprint. Planning (Task B) must start before the current sprint (Task A) ends, so it is start-finish dependent on the current sprint.

Finish-Start Dependency

1
2
3
4

Finish-start dependencies refer to
dependencies where the first task must
finish before the second task can start. This
is the most common type of dependency.

Finish-start dependencies are visually represented as follows, with an arrow going from the end of Task A to the beginning of Task B. Task B does not overlap with the Task A bar in any way. Task A must finish before Task B can begin.

This method of representation can be used in any number of visual representations, including Gantt charts and PERT charts.

An example of a finish-start dependency could be the need to finish designing a feature and knowing what it will do before a user or training manual can start to be written for a product.

Finish-Finish Dependency

1
2

Finish-finish dependencies occur when the first task must
finish before the second task can finish.

1
2
3
4
5

Finish-finish dependencies are visually represented as
follows, with an arrow going from the end of Task A to the
end of Task B. The two tasks are parallel to each other. The
arrow shows how task A must finish before Task B can
finish.

This method of representation can be used in any number of visual representations, including Gantt charts and PERT charts.

An example of a finish-finish dependency could be finishing billing a customer for a product before finishing handing over the product, in order to avoid not being paid for the work.

Critical Path Method (CPM) Charts

Task dependencies are very important and, as mentioned in the previous lesson, they affect schedules and planning techniques. Critical Path Method (CPM) charts are an example of such a task planning method. A CPM chart is a visual way to organize task dependencies.

Creating a CPM Chart

The steps involved in making a CPM chart are:

1. Make a list of tasks needed to finish the project and then create a Work Breakdown Structure (WBS) for those tasks (see the Work Breakdown Structure lesson in Module 1: Introduction to Planning of this course).
2. Add time estimates to each task.
3. Organize the tasks by grouping dependencies horizontally together. For example, a task that is finish-start dependent on another should be grouped next to the task it is dependent on. Arrows can then be used depending on which task dependency is at work to depict the dependency (see Task Dependencies lesson for how to graphically represent different types of task dependencies).

Here is an example of steps 1 through 3 for a project whose goal is to create a spaghetti and meatball dinner with a side salad.

4. From these task groupings, paths can be created. A path is a sequence followed using arrows that you can take from one task to another (with dependencies shown as appropriate).

Paths that go from the beginning to the end of the chart are called beginning-to-end paths. Tasks on different beginning-to-end paths can be completed independently and, therefore, at the same time.

If two or more beginning-to-end paths meet, this is a coordination point for task dependencies—it means that the two or more tasks must be finished before the task they point to can begin. In other words, the tasks must be coordinated.

A CPM chart can have as many beginning-to-end paths and coordination points as needed to finish the project.

The example below shows a number of beginning-to-end paths generated from the Work Breakdown Structure (WBS) from steps 1 through 3 of the spaghetti and meatball dinner project. These paths illustrate the groupings under “Pasta” and “Meatballs” in the WBS.

There are four paths in this example. Following the arrows, these four paths are from:

1
2
3
4

 “Boil the Water” through to “Add Meatballs to Dish”
 “Heat the Pan” through to “Add Meatballs to Dish”
 “Prepare Ingredients” through to “Add Meatballs to Dish”
 “Pre-heat Oven” through to “Add Meatballs to Dish”

There are also three coordination points:

1
2
3
4

 When “Strain the Pasta” and “Heat the Sauce” coordinate before “Put Sauce on Pasta”
 When “Form the Meatballs” and “Pre-heat Oven” coordinate before “Bake the Meatballs”
 When “Put Sauce on Pasta” and “Bake the Meatballs” coordinate before “Add Meatballs
to Dish”

If an overall time estimate is desired, it can be calculated by adding together the longest beginning-to-end path in a CPM chart. This is because all other beginning-to-end paths can happen at the same time. In the example above, “Pre-heat Oven” can occur at the same time as the path “Prepare Ingredients”  “Mix Ingredients”  “Form the Meatballs.”

A beginning-to-end path can also illustrate tasks that occur in parallel. Parallel tasks can occur in any order, as long as they are finished before the final task.

Drawing on the “Caesar Salad” grouping from the WBS example above, it is possible to illustrate parallel tasks.

In this example, there are actually three beginning-to-end paths:

1
2
3

 “Add Croutons”
 “Add Cheese”
 “Add Dressing”

These can occur in any order, as long as they are done before the salad is tossed. They are in parallel.

5. Combine all of the beginning-to-end paths in order to create a full CPM chart.

Here is the full CPM chart for the spaghetti and meatball dinner project.

Critical Paths

CPM charts, once completed, are a useful tool for generating a schedule for the project and determining minimum time estimates. The major way this is done is through the use of critical paths.

A critical path is the longest duration path of tasks between logical points. In other words, a critical path is the beginning-to-end path with the greatest time estimate. It represents the minimum amount of time needed to complete a project, assuming there are enough resources that other beginning-to-end paths can be done at the same. The critical path in the example CPM chart above has been highlighted in blue.

In addition to providing the longest time estimate for the project, critical paths also provide information for longest and shortest time estimates for project tasks. Critical paths highlight the tasks that are critical for the project. These are the tasks along the longest duration path, which represent the minimum time for those tasks. But critical paths also highlight which tasks have slack—the ones on a different beginning-to-end path from the critical path. Because other beginning-to-end paths from the critical path have smaller time estimates, tasks on those paths

can be delayed, as long as the total estimate of the path never exceeds the critical path. This potential extra time for tasks is what gives the estimate slack.

1
2
3
4

Time estimates generated from critical paths in CPM charts may differ from estimates generated from
Work Breakdown Structures (WBS). In a CPM chart, the critical path determines the minimum
estimate and it is assumed (where resources are available) that other paths will be worked on at the
same time. In a WBS estimate, however, each task is added as if one is done after another.

Critical tasks in the critical path should be the first to be scheduled from a CPM chart, because tasks in other paths can be given extra time to finish (within the critical path time limit), without adding to the overall project.

Slack is useful to projects, as it provides a degree of flexibility to certain tasks, without necessarily affecting the target completion date.

Program Evaluation and Review Technique (PERT) Chart

Another task planning tool affected by task dependencies is the Program Evaluation and Review Technique (PERT) chart. Similar to CPM charts, PERT charts are visual representations of a project.

PERT charts use nodes and edges in their network or graphical depictions.

Nodes, usually illustrated as circles, represent milestones. Milestones are not time based, so in a PERT chart, nodes tend to represent some kind of event such as the production of a work product or some other event occurring. In contrast, nodes in CPM charts represent tasks.

Edges, illustrated as lines that connect nodes, represent tasks. In a PERT chart, after lines are drawn, they are further denoted with tasks and time estimates. The lines are also given arrows, to illustrate task dependencies (see the Task Dependencies lesson in this module) and the order tasks must be completed in. A sequence of dependent tasks is therefore represented in a path that follows the direction of the arrows.

If multiple independent paths come out of a node (that is, if multiple lines come out of a node), it means that those tasks can be completed at the same time, assuming time and resources are available. They are in parallel.

1
2
3
4

Alternately, if multiple paths lead towards a node (if multiple arrows point to
a node), it means that these paths must synchronize. In other words, those
paths must be completed around the same time, before the next path
leading out of the node can start.

1

In general, PERT charts make dependencies easier to see.

Example of a PERT Chart

This example draws on the project discussed from the Critical Path Method Charts (CPM Charts) lesson preceding this one, with the hypothetical project whose goal is to create a spaghetti and meatball dinner with a side salad.

1

DID YOU KNOW?

1
2
3
4
5
6

PERT charts were
developed in the 1950s by
the United States Navy.
Their original purpose was
to manage the Polaris
submarine missile program!

The paths for making pasta would look as follows in a PERT chart:

Edges, or the arrows, have been labelled with task and time. Task dependency is clear through the order of the arrows. Nodes, or milestones, have been labelled with numbers. Labelling nodes this way is effective, as numbers are a simple system, but it also allows for nodes to be easily referenced. Each node occurs after at least one event is completed.

Note in this section that there are two independent paths: 1  3  5 can be worked on during the path 1  2  4  5.

The paths for meatball-related tasks would look as follows in a PERT chart:

The paths for salad-related tasks would look as follows in a PERT chart:

Note the parallel tasks here, of “Add Croutons,” “Add Cheese,” “Add Dressing.” These tasks can be done in any order, but all must be completed before the final task of “Toss the Salad” can begin.

Once all the paths have been combined, the complete PERT chart for this example would look like this:

As with building a CPM chart, in a PERT chart, each grouping of tasks should be charted first and then those sections combined. In a PERT chart, this may require cleaning up numbers that overlap for the same task in different sections. For example, node 6 above combined with node 11 in the final chart, and was simply labelled 11 (see below).

Critical Paths

Critical paths are very important in PERT charts. As in CPM charts, the critical path is the path with the longest task time estimates. The critical path actually represents the fastest amount of time the project can be finished it, as all the tasks in the critical path must be finished, but it is assumed that shorter paths can be done within that same time. The critical path is therefore the minimum amount of time a project can take, assuming there are enough resources that other

1
2

Nodes can be identified using any ordering scheme desired. However, using numbers increasing from
left to right allows one to refer to paths in an increasing order.

paths can be completed at the same time. Let us examine the previous example to illustrate this.

The critical path from preparing ingredients through to adding meatballs to the dish (1 2  6  8  1 12) takes a total of 38 minutes. This is the longest task time estimates, as other paths take shorter to finish. 1 5  9  11 12 takes 10 minutes, 1 4  7  9  11  12 takes 18 minutes, 1 8  11 12 takes 32 minutes, and 1 3  10 12 takes 5 minutes. Even though the critical path takes the longest, all of those steps must be finished, so the overall project will take at minimum 38 minutes to finish.

Also as in CPM charts, paths other than the critical path have slack, as they have some room for estimates to change (as long as the path still takes less time than the critical path), without affecting the overall project estimate.

Again, drawing from the above example, the paths 1 5  9  11 12, 1 4  7  9  11 12, 1  8  11 12, and 1 3  10 12, which are all shorter than the critical path, can take some extra time to finish, if necessary, as long as they do not take more time than a total of 38 minutes for the path (or the overall project estimate will change). This flexibility in timing means they have slack.

Any task on the critical path that is extended in terms of time will result in an increase to the minimum time for the project, because there is no slack on the critical path.

In the above example, the critical path of 1 2  6  8  1  12 takes 38 minutes, so the minimum time the project will take is 38 minutes. However, if the original estimate of 6 minutes to finish task 68 is extended to 10 minutes, then the critical path estimate will also change, from 38 minutes to 42 minutes. The minimum time for the project has changed to a total of 42 minutes, as the critical path has no slack.

In a PERT chart, critical paths must be horizontal. In the example above for the project of making a spaghetti and meatball dish with a side salad, the critical path has been outlined in red to be easily identified. As critical paths are always horizontal in PERT charts, they are always easily identified, even if information such as time estimates may not be available. All other paths in the chart must be drawn either above or below the critical path.

CPM Chart or PERT Chart?

In what circumstances is it better to use a CPM chart or a PERT chart? Both can be used to demonstrate project dependencies and to generate time estimates. In other words, both work well for task planning.

In some cases, either chart can be used with success, and it is then a matter of preference for the development team and the project manager. In circumstances where the project may be more task focused, however, the CPM chart is favourable. In CPM charts, additional information can be added to tasks, such as costs. In circumstances where the project may be more event or milestone based, in contrast, the PERT chart is favourable. PERT charts show what tasks need to be completed prior to an event or milestone.

Iteration Plans

As explained in the Release Plans lesson in Module 2: Estimation of this course, planning occurs in both an iteration and a release level. Iteration planning involves dealing with tasks on a detailed level, while release planning deals with broader level user stories.

Release plans therefore plan a few sprints at a time by selecting user stories from the project backlog to be completed and released in a sprint. User stories are chosen for sprints by their priority level. Release planning occurs before iteration planning because it happens before sprints begin.

Iteration plans, on the other hand, are used to manage tasks within a sprint itself. They are based on velocities, task estimates, and available time. Iteration plans ensure that a development team has not over- or under-committed in each iteration. This keeps developers focused on their tasks, makes certain the right tasks are finished, and that the project is on schedule. Iteration plans are key for effective project development and maintaining a sustainable project pace.

Most Agile methodologies, including Scrum and Extreme programming (XP), make use of iteration plans. This lesson uses Scrum terminology such as sprints, product owner, and scrum master to explain iteration plans. For more information on these terms, see the Software Processes and Agile Practices course. The terms iteration and sprints are used synonymously in this lesson as well.

Iteration plans are created in Sprint Planning meetings. Sprint Planning meetings have fixed lengths, set at the beginning of the meeting, and are therefore time-boxed meetings (see the Time Boxing lesson in Module 2: Estimation of this course). As a time-boxed meeting, the length of Sprint Planning meetings must be strictly adhered to so that the meetings themselves stay on topic and that the iteration plans are not over-planned.

Creating an Iteration Plan

The steps involved in creating an Iteration Plan during a Sprint Planning meeting are:

1. Create a Sprint Goal at the beginning of the Spring Planning meeting, if one does not already exist for this sprint within the release plan.

1
2

The Sprint Goal is the general focus for the sprint being planned. Outlining the sprint
goal helps keep the development team focused on relevant tasks throughout the sprint.

2. Report the project velocity from the last sprint. This is an important step, as the previous project velocity will determine the commitments made for the sprint being planned.

1
2

In cases where the last sprint was abnormal, the lowest velocity from previous sprints
should be used.

3. Determine all potential user stories to be completed within the sprint, and break them down into developer tasks.

1
2
3
4
5

TIP: Four hours is
considered a
good amount of
time for a Sprint
Planning meeting.

1

Agile Planning for Software Products | 49

1
2
3
4

User stories selected for completion within the sprint will be informed by the release
plan. However, user stories from the previous sprint that were not considered “done” (for
example, if a story did not pass acceptance tests) should also be included in the iteration
plan for this sprint.

1
2
3
4
5

The number of user stories should be chosen based on the previous sprint’s velocity.
This means that there should only be enough stories within the sprint being planned, so
the sum of their story point estimates is less than or equal to the previous velocity. For
example, if the previous sprint finished 15 story points, then user stories should be
selected for this sprint until they equal 15 story points.

1
2

User stories are also generally chosen based on priority—the most important ones
should be finished first. Any user stories not chosen must wait for a future sprint.

1
2
3
4
5

Once user stories have been chosen for the sprint,
they must then be broken down into developer tasks
by the development team. Clients are not involved
with this task breakdown. A developer task should
only take a day or two to complete.

1
2
3
4
5

After tasks have been broken down, they should be
expressed using techniques such as a Work
Breakdown Structure (WBS), a Critical Path Method
(CPM) chart, a Program Evaluation and Review
Technique (PERT) chart, a Kanban Board, etc.

4. Developers must create an estimate for each task.

1
2
3
4
5
6
7

Any task estimates must be agreed upon by the entire development team. In Scrum,
tasks are considered cross-functional. This means that any developer should be able to
take on any task. However, every developer has a unique pace, so their estimates may
differ for the same task. Task estimates are therefore an agreed average across the
team. Even tasks that require specialized skills, and therefore needs to be done by a
specific person on the development team, must have an estimate that the entire team
agrees upon.

1
2
3

Estimates are given in hours, half-days, or days. Any task with a smaller estimate than
these measures should be grouped with other tasks. Likewise, any task estimated to
take longer than three days should be broken down further.

5. Revisit chosen user stories for the sprint after estimates have been made. Once tasks have estimates, it is easier to ensure they can be realistically done within the sprint.

1
2
3
4
5
6
7

Upon revisiting user stories, if it is found that
they cannot all be finished, then the
commitment for the sprint needs to be adjusted.
User stories and their associated tasks should
be removed from the iteration plan until the total
estimated time matches the available time of
the developers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Kanban Boar ds, first
disc ussed in the c ours e
Softwar e Pr ocess es &
Agile Prac tices of this
spec ialization, ar e a
scheduling s ys tem
developed b y T o yota. T his
s ystem organizes
produc tion in a logical
chain.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Estimates made at the iteration level
override estimates made at the
release level. Iteration level
estimates are more likely to be
accurate, because iteration plans are
more specific. If iteration level
estimates change release level
estimates, the release plan should be
changed accordingly. Typically,
release plans often only look at a few
sprints, and are regularly adjusted.

1
2
3

On the other hand, if it is found that the selected user stories can all be finished within
the sprint with time left, then more user stories can be added, as long as the total time
doesn’t go over the time of the sprint.

6. The development team must sign up for tasks.

1
2
3
4

In iteration plans, tasks are self-assigned. This means that managers do not assign
tasks to members of the development team, but rather, developers choose to work on
what they find interesting. This generally results in more satisfied workers, and better
software.

1
2

Developers should choose tasks based on their available time, so other commitments or
projects the developer is involved in can be accounted for.

Iteration plans allow both the development team and the client to know what to expect from a sprint and what the product at the end of the sprint will look like. The team and the client should be on the same page.

Sample Iteration Plan

SPRINT GOAL: In this sprint, the team is creating the user profile elements. At the completion of this sprint, users should be able to create accounts, log in, and edit their profile.

LAST SPRINT: In the last sprint, we completed 33 story points. It is based on three developers working approximately 40 hours per week for the two-week sprint.

1
2

NAME/
DESCRIPTION

1
2

PRIORIT
Y

1
2
3

SIZE
ESTIMATE
(POINTS)

1
2

ASSIGNED
TO

1

EFFORT ESTIMATE (DAYS)

CREATE DATABASE FOR USER ACCOUNTS

1

1 2 DAVID 3

DESIGN LOGIN PAGE

1

1 2 DAVID 1

DESIGN ACCOUNT CREATION PAGE

1

1 1 CLAIRE 1

DESIGN USER PROFILE PAGE

1

1 1 ALEX 1

PROGRAM DATABASE FUNCTIONALITY TO LOGIN PAGE

1

3 1 DAVID 2

PROGRAM DATABASE FUNCTIONALITY TO ACCOUNT CREATION PAGE

1

3 1 CLAIRE 2

PROGRAM LOGIN PAGE

1

2 1 DAVID 2

PROGRAM ACCOUNT CREATION PAGE

1

2 1 CLAIRE 2

PROGRAM PROFILE PAGE

1

2 2 ALEX 2

WRITE TESTS FOR ACCOUNT LOGIN

1

2 1 DAVID 2

WRITE TESTS FOR ACCOUNT

1

2 1 CLAIRE 2

CREATION

WRITE TESTS FOR USER CHANGING PROFILE PICTURE

1

2 1 ALEX 2

WRITE TESTS FOR USER CHANGING INFORMATION

1

2 1 ALEX 2

RUN ACCEPTANCE TEST ON LOGIN PAGE

1

4 2 DAVID 2

RUN ACCEPTANCE TEST ON ACCOUNT CREATION PAGE

1

4 2 CLAIRE 2

RUN ACCEPTANCE TEST ON PROFILE PAGE

1

4 2 ALEX 2

WRITE USER MANUAL DESCRIPTION FOR LOGIN PAGE

1

4 1 DAVID 1

WRITE USER MANUAL DESCRIPTION FOR CREATING AN ACCOUNT

1

4 1 CLAIRE 1

WRITE USER MANUAL DESCRIPTION FOR CHANGING PROFILE

1

4 1 ALEX 1

TOTAL 25 33

Risks

This module focuses on risks and risk planning. Risks can make even a well-planned Agile project go off track, so it is important to plan for and mitigate risks as much as possible.

Anti-Patterns

Some risks are so common, they create predictable patterns in projects. These risks are known as anti-patterns. Anti-patterns are defined as commonly occurring solutions or situations in a project that cause negative consequences such as project failure. They are the “classics” of risk management and are not project-specific risks.

The best way to avoid anti-patterns is to understand them, so they can be identified and addressed.

Many different types of anti-patterns exist, including:  Anti-patterns from writing code  Software architecture anti-patterns  Management anti-patterns

This module focuses on management anti-patterns. This type of anti-pattern can have many different names, but the concept remains the same: management anti-patterns are ways in which projects fail due to the behaviour of individuals or groups of people.

Only a few anti-patterns are listed in this lesson. For a full list, and accompanying links, see Course Resources.

1

Upon completion of this module, you should be able to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

 Identify, describe, and suggest means of addressing common management anti-patterns,
including: analysis paralysis, cart before the horse, groupthink, silos, vendor lock-in,
overengineering, gold-plating, viewgraph engineering, fire drill and heroics, death march,
micromanagement, seagull management, email as the primary means of communication, loose
cannon, and intellectual violence.
 Understand the difference between group anti-patterns and individual anti-patterns.
 Define the term risk.
 Identify and define types of risks including: scope risk, technology risk, customer and
stakeholder risks, and personnel risks.
 Define the terms impact, likelihood, and value.
 Know how to create and use an impact vs. likelihood matrix and a risk-value matrix to prioritize
risks and features.
 Know how to address different rankings of problems along the impact vs. likelihood matrix and
risk-value matrix.
 Define the terms risk management plan, indicator, action.
 Create a risk management plan.
 Understand that some risks are unforeseeable and must be dealt with as they come.

Group Anti-Patterns

Group anti-patterns refer to risks involving groups of people. The following group anti-patterns are covered in this module:

1
2
3
4
5

 Analysis paralysis
 Cart before the horse
 Groupthink
 Silos
 Vendor lock-in

1
2
3
4
5

 Over-engineering
 Gold plating
 Viewgraph engineering
 Fire drill and heroics
 Death march

Analysis Paralysis

Analysis Paralysis is a group anti-pattern where the development team gets stuck or stalled in some phase of the project, usually from analyzing requirements, leading to paralysis of the project.

This commonly happens in the specification phase of the project. It is during this phase that projects are likely delayed because clients and/or product managers spend a lot of time analyzing requirements and cannot decide on a direction for the project until the analysis is perfected.

Although wanting to avoid choosing the wrong path is admirable, spending long periods of time waiting for information is not in the spirit of Agile methodology. Instead, progress should be at a constant pace in a project—so as to avoid unhappy developers.

To avoid this anti-pattern, a good strategy is run a project with incremental releases, as embraced in Agile. With incremental releases, not everything needs to be known upfront because it is understood the product must be flexible and will change and refine over time.

Cart Before the Horse

Cart before the horse is also a group anti-pattern. The name of this anti-pattern comes from the English idiom, “putting the cart before the horse.” This phrase means that something was put in a counter-productive order, just like putting a cart in front a horse is less productive than having the horse pull a cart. In software product management, cart before the horse similarly means putting too much emphasis on a part of the project that should be done later.

1
2

In the course Software Processes and Agile Practices, you learned about the Agile practice of Lean
Software Design. One of the seven principles of Lean is:

1

“Deliver as fast as possible”

1
2
3

This principle means the product should evolve through a series of rapid iterations. This is
advantageous not only for avoiding analysis paralysis, but because it allows the client to give feedback
and it places focus on core product features.

This anti-pattern might be easier understood through an example. If less time and resources are spent developing a critical feature of a product than on a less critical one, or a feature that is not required at the moment, this is an example of cart before the horse. This frequently happens when programmers assign themselves work that doesn’t directly impact current features, in order to get a “head start” on future work. However, the danger of this process is that a team can find themselves with a lot of poorly developed features of varying importance.

To avoid this anti-pattern, it is important for the development team to understand development priorities and stay focused on those priorities. In other words, the team should clearly understand what work is to be done now and what work is to be done later.

Groupthink

Groupthink is a group anti-pattern that refers to how people tend to follow the general opinions of a group, regardless of whether or not their own individual opinions are different. The term comes from the social sciences. Groupthink can lead to poor decisions and judgments in project development.

The most common example of groupthink is in group discussion on projects, when ideas tend to come from only one or two people in a meeting, while most other members are quiet and go along with suggestions. This can lead to a poor end product, because often other or better options are not discussed.

To avoid groupthink, there are a couple of good measures to take. First, it is important to remember that conflict can be a good thing in group discussions, if done constructively. Creating an open atmosphere of discussion, where different perspectives are encouraged, is very helpful in combating groupthink.

Another means of addressing groupthink is to generate solutions to problems silently, as in Lean Software Design. This means allowing a team to break up into smaller groups or individuals and encouraging these smaller groups to come up with different designs and alternatives. These suggestions are then combined together. This approach has the benefit of not putting people on the spot.

For a video demonstration of groupthink in action, see the Course Resources.

Silos

Silos are group anti-patterns that occur in the extreme opposite of groupthink. A team separated in smaller groups can be a good strategy, particularly if specialized groups create

1
2
3
4

In the course Software Processes and
Agile Practices, you learned about the
Agile practice of Lean Software Design.
One of the seven principles of Lean is:

1

“Eliminate waste”

1
2
3
4
5
6
7
8
9

This principle means that it is important for
the development team to be careful of
being “busy” instead of being productive. A
busy team can get distracted by “extra”
features, which can ultimately interfere with
the functionality of the end product, rather
than focus on developing the core
requirements. This is wasteful and should
be avoided.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

In the course Software Processes and
Agile Practices, you learned about the
Agile practice of Lean Software Design.
Lean Software Design solves the issue of
groupthink by allowing individuals to come
up with solutions to designs and other
problems on paper, without talking. This is
what generating solutions “silently” means.
Then, in a group, each person’s idea is
discussed in turn, and a final solution
combining the entire group’s designs is
created.

more effective work, but this then runs the risk of teams losing touch with each other and limiting communication. This is called working in silos.

In essence, silos are created when a lack of communication among groups on the development team occurs, which lead to a loss of unified focus and the creation of counterproductive strategies and product features. Features developed in silos are developed in a vacuum, so the work of one team could be different or incompatible with that of another team, and bringing the work of two different teams together could thus prove difficult.

To address this problem, it is important to encourage an open and positive atmosphere where team communication and collaboration is favoured. This also encourages the development team to be less apathetic. Alternately, re-examining management structure could also be beneficial. If there is flat management where developers are able to speak directly to other developers instead of going through managers or the managers of other teams, communication can flow easier and bureaucracy can be avoided. In both cases, face-to-face communication should be encouraged.

Vendor Lock-in

Vendor lock-in is a group anti-pattern that occurs when a development team creates a product that relies heavily on a single technology solution or vendor. Vendor lock-in is different from choosing a technology because it is the best option, but rather it generally involves a lack of flexibility in moving to another technology without substantial costs.

The heavy reliance on a single technology as a project moves forward is problematic if the technology cannot cover what is needed, becomes outdated, or cannot adapt to change. In extreme cases, staff can even leave an organization over vendor lock-in.

To avoid this risk, it is important to do research before committing to a technology or a solution, regardless of recommendations made to the project.

Over-engineering

Over-engineering is a group anti-pattern that relates to how the development team creates the product itself. It occurs when a product is made more complex than necessary, such as when extra or needless features are added to a product, making it confusing for the majority of users. Over-engineering can happen on both the user interface (UI) of a product or in its internal processes.

There are many examples of over-engineering, such as digital cameras with too much features that must be set before functionality is enabled, music players with too many options, cars that can achieve speeds that it will never run at, or text editors with too many save options.

To avoid over-engineering, it is important that the development team clearly understands the needs of a product (what the product needs to be able to do) versus the wants of a product (what would be nice if the product could do but is not necessary for success). In the course Client Needs and Software Requirements, determining “needs” and “wants” was discussed at length, including the importance of prioritizing requirements and ensuring a project is feasible.

Gold Plating

Gold plating is a group anti-pattern that relates to how a development team creates a product, much like over-engineering. It occurs when so much effort is put into one part of a project that it reaches a point of diminishing returns. In other words, so much extra effort is focused on a part of the project that it no longer contributes value to the product.

This usually occurs when the development team adds extra features to a product in order to impress the client, particularly when the team finishes early. However, added features can add unforeseen, extra work to a project, and features that the client did not actually want in the product (remember that user requirements should be specified by the client and not by the development team). This can make the client disappointed and confused in the end product.

To avoid gold plating, the development team should stop working when the product functions well. If the team feels new features should be added, the features must first be vetted with the client. Good questions to ask when considering adding extra features include:

1
2
3

 Does this feature improve the product?
 Does this feature make the product confusing somehow?
 Does this feature take away from main functionality?

Another solution to avoiding gold plating could be conducting a user study. A user study involves taking a small sample of users and asking them to try out new features on a product and provide feedback. This feedback can inform the team on how useful the feature is, how it affects the interface, whether or not the feature has broad appeal, and how the product itself can be improved. Not all extra features are bad things, but these steps help to ensure that the extra features actually add value to the product.

Viewgraph Engineering

Viewgraph engineering is a group anti-pattern that occurs when too little effort is put into a project. It is the opposite of gold plating in that way. However, if gold plating is unfocused work, viewgraph engineering is working on what is not important.

Viewgraph engineering is not the same as hiring bad developers and missing deadlines, which is also a risk but a separate issue. Instead, viewgraph engineering is more directly tied to management practices and how those practices can make project work difficult for developers by requiring them to work on things other than development work, such as documentation, reports, or creating presentations. The time spent on such activities should not be greater than the time spent writing code or developing a project.

This anti-pattern commonly occurs in organizations with vertical management structures, where developers must constantly analyze the potential of a concept and prove it to management before going forward. In this way, viewgraph engineering is a kind of analysis paralysis on an organizational level.

Agile methods purposefully seek to avoid viewgraph engineering by placing focus on creating working software over comprehensive documentation. Although documentation should still be produced, it should not lead to unfocused development work.

In a similar vein, the best solution to viewgraph engineering is to remove any barriers developers might face in developing a project. Creating a basic prototype is often more informative than any report or presentation, so time spent on such documentation may be better served in development. If the prototype is good, then it can be built upon. If it is not good, then it can be scrapped, and the team will learn for going forward in both the project, and future projects.

Fire Drills (Heroics)

Fire drills and heroics are two types of linked grouped anti-patterns. Both are very common.

Fire drills happen when the development team does very little work throughout most of the project and then makes a big push towards the end of the project, resulting in overtime work in order to meet deadlines. This leads to a loss of quality in favour of producing a product quickly. Fire drills can have many causes, including:

1
2
3

 Bad management practices
 Developers wasting time
 Expectations were not properly established with the client

Fire drills can also lead to heroics. Heroics is an anti-pattern where the development team ends up relying on only one person’s technical skills to get the project done. This requires that one developer to have almost superhuman skills, as he or she take on almost the entire project. Further, the team relies on only one person, which is bad for both the team and the developer.

To avoid fire drills and heroics, it is important to establish expectations with the client early on the project and to follow Agile software development practices. For example, using time boxes and always producing a working product at the end of those time boxes. These strategies keep the team working at a stead pace, avoiding both fire drills and heroics. They will also keep up team motivation for the project.

Death March

Death march is a group anti-pattern that happens when the development team and the management team are at odds, because the management team is enforcing a path for the project that the development team does not believe in. This leads the development team to lose conviction and passion for the project, which increases likelihood of project failure. In spite of this, everyone keeps working out of a sense of obligation.

Death marches can occur because of financial reasons, or when management is too stubborn to recognize other ideas and the potential failure of the project. In either case, if developer morale is low, then the quality of the product will suffer.

To avoid death marches, it is important for management to maintain open communication with the development team. In other words, managers should listen to what the team thinks about the direction of the project and be willing to explore other alternatives in project development. In some cases, simply reassuring the development team that you understand and recognize their concerns is all that is needed to avoid a death march.

Individual Anti-Patterns

Individual anti-patterns are anti-patterns caused by individuals instead of group behaviour. Individuals caught up in these anti-patterns usually find it hard to recognize it, but people outside the situation can identify these anti-patterns easily. In general, work cultures that promote open mindedness, self-reflection, and improvement greatly help to counter individual anti-patterns.

The following individual anti-patterns are covered in this lesson:  Micromanagement  Seagull management  Email as the primary means of communication  Loose cannons  Intellectual violence

The first two anti-patterns listed arise from the actions of individual managers, while the last two come from the actions of individual team members.

Micromanagement

Micromanagement is a very common individual anti-pattern. It occurs when a manager is very controlling and wants to be involved in every detail of a project, no matter how small. The manager needs to constantly know what their developers are doing. It demonstrates a lack of trust in the development team, which affects team morale and product quality. This can become exacerbated if the team is blamed for the manager’s behaviour.

Micromanagers, in general, do not micromanage with the intention of bringing down developer morale. Instead, they usually think that a project will fall apart without them. Micromanagement is therefore usually born out of a manager’s own internal fears, insecurities, or basic stresses. It can also be caused by overly ambitious timelines, poor product quality, or fear that developers are not up to the job.

Addressing micromanagement can be difficult, as there is no quick and easy fix. In general, micromanagers themselves have to provide a solution. Micromanager has to admit their behaviour is affecting the team and be willing to make steps towards improving their behaviour. Further management training may be needed before micromanagers can adjust their actions.

It is worth noting that wanting to stay informed on project progress should not be confused with micromanagement—in fact, asking for short daily meetings updating project progress is good Agile practice!

Seagull Management

Seagull management is an individual anti-pattern that happens when a manager is only present when problems arise or right before deadlines. This results in an otherwise absent manager swooping in, dumping a lot of information or requests on the development team, and then disappearing again. This can cause a lot of stress for the team and can easily push a project into become a fire drill project. Further, the development team will be working in constant fear of when the next dump will be.

The behaviour of seagull managers is usually caused by a number of factors, such as busy schedules, inadequate planning, or stress. Addressing seagull management behaviour involves allowing a manager to lighten their workload (although this might not always be a solution that product managers can employ, because it depends on things outside the scope of the managers themselves). In general, if you suspect you might be a seagull manager, it is a good idea to re-evaluate your schedule and how you interact with the development team.

Email as the Primary Means of Communication

Email as the primary means of communication is such a common issue in projects that it has become its own anti-pattern. The methods of communication used between managers and development teams can greatly impact a project. Email, in particular, lends itself to creating seagull managers who only write to the team with large workloads or big dumps of information, and do not communicate frequently otherwise (see above). Further, email is often not the best way for the team to communicate well with managers because it can be difficult to provide context in emails, or alternately, information can be easily misunderstood. Emails can also be too formal for most communications.

To address this anti-pattern, it is important that managers and development teams take time to communicate in person. When that is not possible, other means of communication such as chat services, video conferencing, and phone calls are good alternatives to email. All of these forms of communication have the added benefit of giving respect and attention to team members, which help to increase team motivation.

Loose Cannon

A loose cannon is an individual anti-pattern. The term “loose cannon” itself refers to an unpredictable person (or thing) who can negatively affect others, unless it is managed somehow. In software projects, loose cannons tend to be people who make significant project decisions without consulting the rest of the team. This behaviour is reckless and can create more work for other group members.

A loose cannon is not to be confused with someone who asserts their opinions on every topic, leading to poor project decisions. This is more closely related to the anti-pattern of intellectual violence, discussed below. Like many individual anti-patterns, there is no quick fix to loose cannons. Often, dealing with loose cannons involves understanding the motivations of the individual’s behaviour. Are they trying to cause trouble? Are they trying to prove their work to the team?

Once this is understood, a manager or team can try and get the individual to understand that their behaviour is destructive and encourage the individual to make steps to change it. In some cases, organizational steps might be necessary to address the problem if the personality of the

1

MORE INFORMATION

1
2
3
4
5
6

The origin of the term “loose cannon” comes from
the 17th and 19th centuries when wooden sailing
ships used cannons as weapons. When a cannon is
fired, it undergoes a large amount of recoil. To avoid
damage from this recoil, cannons were tightly
secured to decks using ropes.

1
2
3
4

A loose cannon refers to a cannon that has come
free of these restraints, allowing it to roll around the
ship and cause damage. The term has survived until
this day!

loose cannon makes change very difficult. In any case, loose cannons should be dealt with quickly or the risk to a project will increase over time.

Intellectual Violence

Intellectual violence is an individual anti-pattern that concerns a person who asserts their opinion on every topic and impedes progress by questioning every decision and action or using their advanced knowledge in an area to intimidate or look down on other team members. These individuals tend to repeat their opinions so much that the rest of the group concedes to them just to avoid confrontation. In turn, this can lead to low team morale, with bitterness and apathy among group members that affects open communication and productivity. Loose cannons are sometimes the cause of intellectual violence.

There are a couple of strategies for addressing intellectual violence. The project manager can try talking to the individual in private about his or her behaviour and suggest any appropriate changes. Alternately, the project manager can encourage an open question policy (for example, reinforcing the idea that there is no such thing as a stupid question), and discourage prejudging opinions or inexperience. Intellectual violence should be addressed quickly to prevent a project from taking a bad direction and to keep up team morale.

Causes of Failures

Projects can fail not only from issues that present themselves as patterns, but also from project risks. Risk is something that could potentially cause a project to fail. Risks are found in every situation, not just in projects and project plans, so it is important to try and plan for them.

There are many different types of risks. These include:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

 Scope risks, which refer to risks that involve expanding requirements. Agile methods
are well equipped to address scope risks, because Agile has good change control
measures. In other words, Agile deals well with change and changing requirements.
 Technology risks, which refer to risks that the technology used in a project will fail. This
includes hardware failure, software protocols becoming obsolete or unsupported, lack of
scalability with technology, or a lack of technological understanding on the part of the
development team.
 Customer and stakeholder risks, which refers to risks that customers and stakeholders
can bring to a project. These usually occur when customers promise to provide material
or information to the team and they forget or deliver it late. Examples of customer or
stakeholder risks include clients becoming apathetic or a change in the main point of
contact between the team and the client.
 Personnel risks, which refer to risks posed by personnel on the development team. For
example, team members may leave partway through a project. This can be especially
problematic if the person who leaves has specialized skills that are not shared by other
team members. Personnel risks could also refer to a lack of needed skills, conflict
between team members, or communication issues, such as groupthink.
 Many other risks, such as legal issues, security problems, the destruction of physical
locations, loss of interest from either management or development teams, industrial
espionage, etc.

Risk Assessment, Likelihood, and Impact

In order to plan for risks, it is important not only to be able to identify potential risks, but to understand both the likelihood of a risk happening over the course of a project and the impact of that risk on the project.

Risks may include the anti-patterns as discussed above as well as project-specific problems that may not be common. In order to assess risks, their likelihoods, and impacts, the first step is to create a list of risks. You should recognize that you can take action to avoid some risks, but this is not always possible.

Once risks have been identified, they can be prioritized. One of the most useful ways of prioritizing risks is using an impact vs. likelihood matrix.

Impact vs. Likelihood Matrix

An impact vs. likelihood matrix is a two-dimensional representation of the amount of impact a risk has on the project and how likely that impact is to happen. With this knowledge, risks can prioritized, and the team will know what to focus on preventing, and what to monitor.

In an impact vs. likelihood matrix, impact runs along the y-axis, from low to high. Likelihood runs along the x-axis, also from high to low. Different grids in the matrix are assigned different rankings based on how high the impact and likelihood is.

To use the matrix, the listed risks of the project should be assigned a value from the matrix based on their value along each axis. For example, if your project has identified the risk “project runs out of funding,” this is potentially a big risk. It is high on impact. But, if this only has a medium likelihood of occurring, then it would go in the middle column of the matrix, at the top of the grid.

Risks can range quite broadly, from being an immediate impact to something with a very slim likelihood, like “asteroid destroys the Earth.”

The numbers in each cell of the matrix represents a different risk ranking, as determined by each risk’s value on the matrix. For the examples above, “project runs out of funding” has a risk ranking of 2, as seen in middle column of the top row. The risk “asteroid destroys the Earth” is a large impact, so it is in the top row. However, it also has a low likelihood, so it will be in the third column. It will therefore be situated in the bottom-right square, and has a risk ranking of 3.

After a list of risks has been made and assigned rankings, the team is informed of the potential magnitude of risks the project faces, so appropriate action can be taken regarding the risks.

Based on the ranking of the risk, the following actions are recommended:  If there is a ranking of 1, then the team needs to mitigate the damage. The risk needs to be addressed as thoroughly as possible and quickly, as it is the most dangerous.  If there is a ranking of 2, then the team should be concerned about the risk but do not need to take immediate action, since it is only moderately likely to happen. A strategy should be developed, however, for dealing with the risk should it come to pass.  If there is a ranking of 3, then the team should spend very little time considering the risk, as it is not of great concern to the project and it is the least threatening.

Other variations on the impact vs. likelihood matrix are possible. Some projects may assign risk rankings differently. For example, some projects may assign a ranking of 1 to the high impact/high likelihood cell in the top left, as above, but also to the cells of high impact/medium likelihood and medium impact/high likelihood. In this scenario, a ranking of 2 is assigned to cells on the edges of those cells with a ranking of 1, and 3 to everything else. This puts a higher importance on some risks, which is known as decreasing a project’s risk tolerance. This practice is important for mission-critical projects—projects that are important to a business or company, because they are tied to the success of that business or company.

Any actions taken to deal with risks adds activities to the project plan. These activities should be taken into account because they can influence both project deadlines and costs.

Risk-Value Matrix

A matrix is a useful tool that can also be applied to project features. This kind of matrix is known as a risk-value matrix. It is similar to an impact vs. likelihood matrix, but it focuses on showing how likely a risk is to influence the value of a project feature.

Accordingly, the y-axis of a risk-value matrix shows risk, while the x-axis shows the value of the feature to the project. Instead of assessing risks with the matrix, features are assessed. This helps prioritize which features the development team should work on first. For example, consider the hypothetic project of building a mobile app with a database to store data. Let’s say the development team is very experienced in creating databases but has little experience creating mobile apps. In this case, on a risk-value matrix, database features are low risk and high value, while app features are high risk and high value.

Using the ranking information the risk-value matrix provided, development priority can be assigned—those features that are high risk and high value should always be prioritized first. In this case, developing app features should be done first. Although instinct suggests that it is better to start with developing high value and low risk features first, as it theoretically be done with more ease, this is wrong. Tasks with high risk pose the most danger to success, and problems associated with these tasks should be tackled quickly. This way, any issues that may

cause delay or cancellation can be identified earlier in the project, rather than later, and time and work is not lost working on other features.

Risk Strategies, Contingency, Mitigation

In addition to be able to identify risks, likelihood, impact, and effects on project feature values, it important to be able to create a risk plan and implement it.

A risk plan, or a risk management plan, is a list of potential project risks, associated impacts, and likelihood, and any planned action for how to address the risk should it occur. Generally, risk management plans are presented in tables.

The table consists of four columns. From left to right, these columns contain:  The risk  The associated rank of that risk, as determined by the impact vs. likelihood matrix  A description of the risk’s indicators (An indicator is a sign that the risk is going to occur and is usually some sort of event or activity to look out for.)  A description of the action to take if the risk presents itself

A risk management plan is better understood through an example. Imagine a project that seeks to create a music player app. In order to have a functional app, the client needs to obtain copyright access to the content they wish to provide users.

In an impact vs. likelihood matrix, it is determined that the risk “unable to obtain copyright to music for app” has a ranking of 2. It is high impact but only moderately likely to happen. Indicators that a failure to obtain copyright has occurred include clients or musicians communicating this to the team or if clients or musicians lose interest in the app. A number of actions can be taken to address this issue, such as:

1
2
3
4
5
6
7

 Ensuring the development team delivers the product in increments, so the client can see
progress in the product and remain actively involved and interested in it.
 Settling financials of the project appropriately, so there is a guarantee that work done will
be compensated.
 Some product managers may get involved with helping the client obtain copyright. This
level of involvement largely depends on the scope of the individual position of the
product manager.

In a risk management plan table, it would look like:

1
2

Risk Risk
Ranking

1

Indicators Action

1
2
3

Unable to obtain
copyright to music for
app

(^2)  Musicians or client communicate difficulties in obtaining copyright  Musicians or client lose interest in app  Deliver project in increments so progress is visible to client  Settle financials ahead of time so there is no risk of not being paid for work  Help client gain copyright access Using a risk management plan for all risks ranked as 1 or 2 will greatly increase the potential success of the project. Even with risk management plans, it is very important that the product manager and development team recognize that there will always be risks that cannot be predicted or planned for, as every project will face unique risks. However, this does not mean that risk planning should be ignored. Product managers should recognize that dealing with the unknown is a skill they will need to develop. In cases of unforeseen risks, project success will largely depend on how those risks are dealt with in the moment.

Reviews & Metrics for Software Improvements

Course Overview

**Upon completion of this course, you should be able to: **

• Understand the continuous feedback gained from different reviews and metrics that can be applied to any of the three goals of software development in order to create improvements for the work and product.
• Explain Sprint Review Meetings and what are part of Sprint Review Meetings.
• Explain the concept of user studies and how they can subjectively and objectively provide feedback.
• Provide example measures of product success.
• List and explain industry examples of processes used to create successful products.
• Explain peer review techniques used to improve project work.
• Define metrics and desirable properties of metrics, including popular metrics and defect-related metrics.
• Explain the Agile practice of Daily Scrum.
• Use various techniques such as velocity, Release Burndown Charts, Task Boards, and Iteration Burndown Charts to help monitor product development.
• Define retrospectives and exercises used in retrospectives.
• Apply retrospectives at the end of a sprint or project to improve the overall product or future products.

Introduction

Welcome to the Reviews and Metrics for Software Improvements course, within the Software Product Management Specialization. This course will focus on what happens once development has begun, in order to keep things Agile and on target.

The first two courses of this specialization, Software Processes and Agile Practices and Client Needs and Software Requirements serve as foundational pillars in learning Agile—they are the “legs” of the inukshuk that depicts the structure of our specialization. The third course, Agile Planning for Software Products serves as the body of the inukshuk, which builds on the first two courses. This fourth course, Reviews and Metrics for Software Improvements

serves as the arms of the inukshuk, which builds upon not only the first two courses, but the third one as well. This means that Reviews and Metrics for Software Improvements brings together many of the fundamentals of the prior courses.

In other words, the fundamentals of this course – ensuring that the project is Agile and on target – begin after a product opportunity has been identified, potential users have been talked to, requirements have been defined, releases have been mapped out, and developers are in the process of designing and implementing the product.

Over the past three courses, you learned that building better software involves three goals:

• the right product
• done right
• managed right

This course outlines techniques used to determine if these goals are aligned. Specific types of reviews and metrics should be used for each goal to gain continuous feedback. This feedback can take the form of subjective or objective data.

Based on this data, improvements to the product itself, the underlying process, and the overall project can be continuously determined. As issues are addressed, the software becomes better and better.

For the right product, the software product manager and development team must:

• demo the product early to gain feedback early.
• observe users and how they engage with the product.
• gauge the effectiveness and efficiency of the product.
• collect data on user satisfaction.
• collect information about the product success in the market.

All of this can be used to identify what needs to improve in the product’s features. For the product to be done right, the development team must:

• review and inspect the work products created in order to identify any repair issues as soon as possible.
• monitor data about important quality factors of the work (e.g., defect rates).

All this information can be used to identify what needs to improve in product implementation and what needs to be adjusted for the product to achieve its desired quality.

To manage right, the development team must:

• meet briefly each day to update and synchronize with other members.
• track measurements, such as velocity.
• monitor the completion of planned user stories or tasks within a sprint, in a way that is transparent to everyone.

This information can used to coordinate the team and the work the team produces. It can also be used to identify work that needs improvement in order to become more efficient and less wasteful.

There are four modules in this course.

Module 1 covers reviews and metrics related to creating the right product, including:

• Sprint Review Meetings, where the product is demoed after a sprint and reviewed by stakeholders and other project members to produce feedback
• user studies that suggest improvements based on observations on how users interact with a product
• example measures for product success
• processes used in the industry to create successful, well-designed products

Module 2 covers reviews and metrics related to making sure the product is done right, including:

• peer review techniques used by developers to inspect and improve their work
• metrics and how they fit into addressing specific questions involving product goals or processes
• the desirable properties of good software metrics
• popular metrics and defect-related metrics

Module 3 covers reviews and metrics related to managing a product right, including:

• the common Agile practice of Daily Scrum
• a review of the concept of velocity
• Release Burndown Charts, which track completed user stories over successive sprints
• Task Boards and Iteration Burndown Charts, which track completed tasks within a sprint and help identify work that is only half done

Module 4 covers reviews and metrics related to learning from experiences on the project, including:

• retrospectives or practices based on lessons learned, which can be applied at the end of a sprint or project
• exercises related to project retrospective, which identify successes, reveal shortcomings, revisit what happened, recognize all contributors, and produce constructive lessons to carry into future projects

Right Product

**Upon completion of this module, you should be able to: **

• Explain the term monitoring, and the goals of monitoring.
• Explain the term feedback.
  • Identify different types of feedback.
• Explain the term verification, the term validation, and the difference between the two.
• Explain the terms Sprint Review Meeting, Client Demo, Definition of Done, and Stakeholder.
• Explain the difference between a Sprint Review Meeting and a Sprint Retrospective Meeting.
• Explain the three main parts of a Sprint Review Meeting: the client demo, the Product owner approval, and the stakeholder feedback.
• Understand that although clients can suggest improvements or requirements mid-sprint, these can only be added to the backlog during a sprint.
• Explain the terms user study and usability.
• Summarize different types of user studies, and how to gather data for them.
• Explain why both objective and subjective measures in user studies are important.
• Recognize that the above practices are grounded in the industry.
• Identify the different processes used by different companies.

Introduction to Monitoring

This module focuses on ensuring the right product is being delivered by the software product manager and development team. It will cover techniques related to this goal, including:

• Sprint Review Meetings
• User studies
• Industry examples

Terminology Review

Some terms from previous courses are key to understanding these concepts. They are reviewed below:

A verified product refers to one that works the way it was intended to, according to a set of requirements. This concept has been addressed before in both the courses Introduction to Software Product Management and Software Processes and Agile Practices.

Verification is commonly fulfilled through the use of unit and acceptance tests. Unit tests are tests that verify specific, low-level functionalities. In other words, they ensure the software goal of being built right. In test-driven development, unit tests are written before source code for the feature.

A validated product, on the other hand, refers to a released software product that satisfies its stakeholders. Validation ensures the software goal of the right product. A good product has validation from all stakeholders, which includes anyone affected by or who has an effect on the success of the product. Both clients and end-users are examples of stakeholders. Validation aligns with the Agile Manifesto principle,

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

This concept has also been addressed before in both the courses Introduction to Software Product Management and Software Processes and Agile Practices.

Validation can be obtained from clients through frequent demos and open communication. Validation can be obtained from users through techniques such as user studies, surveys, or focus groups. In both cases, the information obtained is used to sure the right product is being built.

New Terminology

Monitoring refers to the tracking, reviewing, and evaluation of the product and process of the software development being undertaken. It is an essential part of meeting the goals of software development (the right product, done right, and managed right).

Monitoring is important to Agile, as it allows everyone to know the status of a project at any given time. Therefore, project transparency is also an important aspect of Agile.

Metrics are used in development to measure various aspects of a

product, process, or project. Metrics provide quantifiable data and You will examine results to accomplish this. They are actually a means of monitoring. metrics in more detail However, it is important to remember not all important aspects of a in the second module

of this course! project are quantifiable, and not everything that can be quantified is

necessarily important to a project.

Both monitoring and metrics help software product managers and development teams obtain feedback. Feedback is information or criticism that can be used to identify improvements in a product or process or to affirm that the project is on the right track. In fact, feedback can be used to improve or verify not only the product or process but also the communication or other practices used in the project.

Feedback can come in many forms, both qualitative and quantitative. Calculations, results from user studies, suggestions from the team or clients, and client reactions are all different forms of feedback.

Feedback is important, as Agile is committed to constantly improving a project or a product as often as possible. Continuous feedback allows this. In Lean methodology, feedback is also used when considering different alternatives to decide which option is the best for the project.

Sprint Review Meeting

Sprint review meetings are meetings held at the end of a sprint. They are opportunities for the development team to demonstrate their product and collect feedback from stakeholders. Sprint review meetings are a good technique to use to help determine if the right product is being made.

Sprint review meetings are Scrum events. Scrum is an iterative and incremental Agile software TSIPcrum**:** W e tercmovinoered logSy, cranumd, thSe cruimmpoErvtanenctse, development methodology for managing product of time-boxing in the course on

development. A review of Scrum terminology used in Software Processes and Agile this lesson follows below: Practices. Check that out if you need a

refresher!

• Scrum events are events that the Scrum Master is responsible for facilitating. They generally occur throughout the development process of a project. Examples of Scrum events include sprints, daily stand-ups, sprint review meetings, sprint retrospective meetings, etc.
• A Scrum Master is the role that requires the facilitation of Scrum practices.
• A Product owner is the role that is responsible for product backlog.
• Sprints are synonymous with iterations in this lesson.

Sprint review meetings are the first of two distinctive Scrum events that take place at the end of a sprint. In the Scrum review meeting, the product is demonstrated and discussed. The second Scrum event is known as a sprint retrospective meeting. In the sprint retrospective meeting, the development’s team process is re-evaluated and discussed. Sprint retrospective meetings will be discussed in more detail in a later lesson.

All Scrum events are formal opportunities for the software development manager and development team to gain feedback on their work and product and to evaluate their progress on the project. They are also all time boxed, which means that they cannot exceed a predetermined amount of time.

Sprint review meetings are therefore both opportunities to gain feedback and a time-boxed event. The suggested time for sprint review meetings is an hour for each week of the sprint the review is for. For example, if a sprint took three weeks, then the sprint review meeting should be three hours long.

Roles of a Sprint Review Meeting

There are a number of important roles played by various attendees at a sprint review meeting. Sprint review meetings can be attended by any stakeholder in the project—in other words, any one with interest in the product is invited to the meeting. Typical sprint review meetings are attended by the Scrum master, the Product owner, the Scrum team, management, some customers or end-users, and sometimes developers from other projects.

The Scrum Master, as outlined above, facilitates the sprint review meeting. This involves making sure that the conversations during the meeting stay focused and on task. For example, Scrum masters ensure that suggestions are addressed at the end of the meeting, and they remind other meeting members of that when necessary. The Scrum master is also responsible for ensuring that people only voice relevant comments and that questions are asked or feedback provided appropriately.

The development team also plays an important role in sprint review meetings. The development team is responsible for running the meeting. Everyone on the team should have a turn to speak or give input in the meeting, because everyone on the team has played a part in creating the product.

The Product owner, as outlined above, is responsible for the product backlog. This means that the Product owner must approve features of the product and ensure that the Scrum team is following the Product owner’s vision. Other stakeholders, such as users, also contribute to sprint review meetings by providing feedback and improvements at the end of a meeting.

Sprint Review Meeting Outline

Sprint review meetings are informal events. They are focused on demonstrating the product as finished by the end of the sprint. The general rule is that the development team should not be distracted or spend extra work creating slide presentations or other products for the meeting. Instead, demonstrations should need minimal preparation outside of the work that went into developing the software.

A sprint review meeting begins when the Scrum master introduces the outline for the meeting, which includes information such as the order of speakers and when members are allowed to make suggestions (generally at the end of the meeting). The goal of the sprint that is finishing is then reviewed, to help give perspective to the meeting.

Sprint review meetings generally consist of three main parts, which follow after the meeting outline and sprint goals have been explained.

1. The product is demonstrated. During this part, the Scrum team demos the product as realistically as possible on the platform the product was meant for. For example, a mobile app should be demonstrated on a mobile device.

The product demonstrated should also be authentic. This means that what is demoed should legitimately be the product as it currently exists. It should not appear to work when it actually does not work. For example, features should not be hard coded for the demonstration so that they only work with specific input values. Only features that are truly ready and have met the definition of done should be demoed. Anything incomplete should be saved for a future sprint review, when they are done.

2. The product and features demonstrated are approved by the Product owner. Once features have been approved by the Product owner, they should also be removed from the product backlog. Removing items from the backlog can take place at the Sprint Review Meeting. Alternatively, the Product owner may also wish to take more time to fully evaluate the product, and features can be removed from the product backlog after the meeting, once the Product owner has had a chance to examine it in detail.
3. Stakeholders provide feedback on the product after it has been approved by asking questions, suggesting features, or providing other commentary.

In general, feedback takes three different forms:

• praise for the feature if it is on track
• suggested areas for change or improvement
• identifying areas or issues that lead to questions, new problems, or a revision of assumptions

Stakeholders can also suggest as many new features as they like during this time. Remember that the product backlog is maintained and prioritized by the Product owner, not by the development team. Ultimately, the Product owner is the one who decides if and when a feature will be developed for the product.

Sprint review meetings allow the Scrum team to showcase their hard work while also increasing project transparency. The meetings provide a good opportunity to gather feedback on the work produced so far. Sprint review meetings also serve as something for the Scrum team to work towards, as it encourages the creation of working software.

User Studies

User studies are another means of validating that the right product is being created, by focusing on end users.

In the Client Needs and Software Requirements course of this specialization, usability was discussed in the context of creating a product that works well for users but also appeals to users. Users will not use a product that they do not like or that they cannot use.

**DID YOU KNOW? **

The desire to assess the ability of computer systems in their usefulness to humans has existed in many forms since computer systems have been designed. It has appeared under the terms ergonomics, ease of use, and then more recently, usability.

The International Organization for Standardization (ISO) has defined usability as the measure of “effectiveness, efficiency, and satisfaction with which specified users can achieve goals in particular environments” (ISO, 1998, p. 2). User studies measure the usability of a product.

Usability testing can take place on a user interface, such as a website, but can also test any kind of product. Because of that, in some cases, it is also known as product testing.

Key Aspects of User Studies

There are a number of key aspects of user studies that the definition of usability touches upon.

As explained in the previous section, user studies measure usability. This is done by measuring the three different elements of usability:

• Effectiveness
• Efficiency
• Satisfaction

Most often user studies focus on effectiveness and efficiency and assume that satisfaction will result from doing well in both those elements. However, even though there can be a correlation, this is not always true.

Various types of research methods can be employed in user studies. Research methods tend to depend on product design and the type of information the team desires to obtain.

Examples of research methods include exploratory studies, direct observation, etc. User studies are also conducted alongside other processes; such as interface design or product conceptualization.**

In general, user studies give a certain number of users a set of goals to achieve by using the software product in question. This must all be conducted in a particular environment. All software products are created to achieve goals. Even products like games have an intended use. Through observation or collecting data on users, usability studies can determine if the software product is achieving its goal in the intended way and how easy it is to do so. They can also uncover if the user is using the product in an unintended way to achieve that goal, or to achieve a new goal entirely, and why this might be happening.

Whether or not a user achieves a specified goal measures the effectiveness of the product. Efficiency can be determined by how quickly the user accomplishes their goals. Satisfaction, on the other hand, can be more directly measured through a short interview after the study by asking users if they liked the product and felt confident about achieving goals. These answers might differ from what measured effectiveness or efficiency suggest, which is why satisfaction should be evaluated separately. For example, even if it takes a short amount of time to achieve a task, satisfaction might be low if users did not trust the result.

It is important that user studies select the right end-users for the study. This means those selected must be representative of the target audience of the software product and share similar characteristics. Examples of shared characteristics might be socio-economic, educational, or cultural background, or computer skill level. In fact, identifying target users, their needs and wants are the first things a good project will undertake, often through user research. Users in user studies should be drawn from this same pool of target users.

In general, the family and friends of the There are actually many different kinds of product manager and development team common usability studies. Some are discussed should not be involved in user studies below, but for a more thorough examination on because they may provide biased different kinds of usability studies, see Hornbæk, feedback. 2006 in the Course Resources section. There,

you can find a link to a study from the University of User studies must also be performed in Copenhagen that explores different kinds of

common usability studies. This paper also focuses particular environments. The environment on the challenges that usability studies and

must be controlled, as well as the test research address!

method. This is covered in more depth in

the next section.

Different Types of User Studies

There are two major different types of user studies:

• In some studies, users are provided goals to accomplish.
• In other studies, users are instructed to navigate the software how they would like.

In cases where users must meet specific goals, user studies validate the ability of the product to allow users to achieve those goals. It also reveals parts of the software that may be problematic and prevent users from reaching the goals.

In cases where users are asked to use the product as they like, testers are usually asked to think out loud. The user study seeks to determine what the product naturally encourages users to do, and whether or not that use is different from the intended goal of the software. It may be that different purposes for the product are identified and consequently the product might be adjusted going forward—either to return to its original goal or to change the focus of the product. In both kinds of user studies, users are usually observed and their actions or comments recorded. Observation is often bolstered through questions asked to users. These questions are meant TIP: If you are interested in getting

to help determine how well the product met needs or to better, first-hand knowledge of user

studies, you can often sign up to ipderodntuctify . anThy is nekindga tiovfeobeservxperieationncecans crteaaketedplaceby in thea participate in a user study through

local tech companies. This also has laboratory or through on-location testing and can be the added benefit of helping out local

accomplished through note-taking. However, industry!

observation can also be done remotely through

computer applications or digital capture. Many different software are available to aid in digital capture of user studies, such as through monitoring usage of an app or a web service to determine which features are most used.

Both kinds of user studies can also give feedback on:

• How enjoyable it is to use the product
• The aesthetics of the product
• The product flow

Other notable types of user studies include:

Results from user studies can be determined using both objective and subjective measures.

Objective measures involve quantifiable usability metrics or in other words, anything involving numbers, such as time, the number of page clicks, etc.

Subjective measures involve qualitative usability metrics, which are more opinion based.

Both objective and subjective measures of usability are important, because they might lead to different conclusions regarding a product. For example, if users spend a long time accomplishing a goal, this might seem to be undesirable on paper. However, by using subjective measures, spending a long time accomplishing a goal may have been something users enjoyed, which lead to increased confidence, involvement, satisfaction, and usability.

Subjective measures may also involve qualities that are not obviously related to the task the product sets out to accomplish. These are hedonic qualities, such as originality of the product, beauty, sociability, etc.

Industry Examples

Major companies such as Apple, Google, Intuit, and IBM have also developed their own means of producing the “right product.”

Apple

Apple notably uses prototyping to create their products. Their methods are known as “10-to-3- to-1” or “pixel perfect” prototyping.

“10-to-3-to-1” refers to a type of prototyping where designers initially develop 10 different prototypes without restrictions. This is similar to Lean development, as discussed in the course Software Processes and Agile Practices, where many prototypes are examined before a decision is made on which to pursue. From the 10 prototypes, the top three are chosen and explored further. Then, the top prototype of the three is selected and designed to a “pixel

perfect” level.

Apple’s late stage prototypes are “pixel perfect,” as they have been designed to the point of each individual pixel. In other words, the development team does not just design the interface, they go to the highest level of detail. This method of prototyping is quite expensive. However, Apple yields good results from these methods, so for the company, they are worthwhile.

The Apple company also holds regular reviews through a weekly executive team review. At this meeting, the team goes over its production process. Peer design meetings are also held between design teams and engineers. These meetings focus on improving design.

Google

Google is noted for creating the “Design Sprint” process.

The “design sprint” is a rapid and iterative process. It compresses the work of several weeks or months into a single week. Sometimes, “Design Sprints” are even shorter. This method is in line with the Lean principle to “deliver as fast as possible,” as outlined in the Software Processes and Agile Practices course.

There are five major stages in a “design sprint.” Each stage is meant to take a single day. These stages are:

1. Understand. During this stage, engineers and designers evaluate the problem their product is meant to address and identify their target audience.
2. Diverge. During this stage, participants are encouraged to develop as many solutions as possible for the problem, no matter how far-fetched they may seem.
3. Decide. During this stage, participants vote and discuss which ideas should be pursued in more detail from the previous stage.
4. Prototype. During this stage, participants create sketches and prototypes quickly. These prototypes focus on user interface and experience.
5. Validate. During this stage, products are given or demonstrated to users in order to elicit feedback for designers and engineers.

The “design sprint” has also been used in major companies such as Airbnb and Blue Bottle Coffee.

Intuit

Intuit is a company that creates accounting software. It was founded by Scott Cook, who also developed the process known as “follow-me-home.” This process helps to ensure that the right product is built.

The “follow-me-home” process involves watching a customer install and use the software. It provides developers with the ability to observe the user’s environment first hand, which helps them better meet user needs.

In its initial use, Cook himself would wait for customers in stores, and observe them in their own homes with permission. Modern use of “follow-me-home” is more controlled. Now, Intuit arranges 20 visits per year with different customers. These visits are about an hour long. They still allow developers to take note of the user’s environment and how the software fits into that environment.

In addition to helping to ensure that the right product is built, “follow-me-home” provides validation for the product. This is because it tests the satisfaction of the user, instead of testing whether or not specific functions work as intended.

IBM

International Business Machines (IBM), one of the largest information technology companies, uses the practice “Design Thinking.” This process combines prototyping, user observation, and Agile development. It starts out by identifying the needs of users and comes up with solutions for those needs.

“Design Thinking” was initially created at Stanford University. However, IBM adapted the process to meet their own needs.

The four stages of “design thinking” traditionally include:

• Understand
• Explore
• Prototype
• Evaluate

IBM added three additional stages among those above:

• Sponsor Users
• Hill Statements
• Playbacks

These stages unfold as follows in the IBM process. Developers and designers first seek to understand their users, as well as those users’ needs or the gaps in those needs. Following that, a candidate is identified who would be interested in the product and who can provide insights throughout the development of the product. This candidate, or sponsored user, must share most of the characteristics of the target users.

The sponsored user works with the development team to identify a problem in the product. This is known as the Hill Statement. This problem is then taken to the larger team to solve. A number of solutions are explored, and any ideas that do not work are scrapped.

After solutions have been narrowed, sketches and prototypes are created. Playbacks occur if a few iterations are needed to determine the best idea.

Finally, a working model has been created and can be evaluated with end-users. The model is iteratively refined based on the feedback of the sponsored user. In “design thinking,” a product is actually continually refined based on continuous tests and user needs, even after the product is launched.

Done Right

**Upon completion of this module, you should be able to: **

• Recall the requirements criteria: correct, complete, clear, consistent, verifiable, feasible, traceable, manageable, and simple.
• Explain the different review techniques: software walkthroughs, software technical reviews, software inspections, and requirements technical reviews.
• Summarize important monitoring issues, such as missing metrics, knowing why you are measuring, and quantifying everything.
• Explain the concept of Goal Question Metric, including associated terms: question, goal, and metric.
• Create a metric for an appropriate quality.
• Differentiate between metric, measure, and indicator.
• Explain the desirable properties of a good metric.
• Recognize that popular metrics have a process
• Explain popular metrics used to measure the non-functional requirements of maintainability, complexity, performance, reliability, and success.
• Explain defect analysis.
• Determine rate of defects found and fixed.
• Summarize the concept of software barrier, subsystem, pre-release, post-release, and defect density.
• Explain the relationship of defects with subsystems.
• Recognize when a software is good enough to be released and that it’s better to find defects early.

Review Techniques

The previous module Right Product focused on the software development goal of producing the right product. This module, Done Right focuses on the software development goal of ensuring the product is done right.

This lesson examines important review techniques used to examine the work products created throughout a software project. Review techniques

are meant to help identify defects early, when they DID YOU KNOW?

are cheaper to fix, and to help make sure the

product is created right and the project is on track. The use of peer reviews falls in line with

the Agile software development technique There are many different types of reviews. Some known as pair programming, or peer

programming. In this technique, two

haspeveci alalizatreaiondy , suchbeen as exsprinploredt retvihreouwghmoueet tingthis.s programmers work together in developing

a feature. Both write the code, while both Reviews examined in this module are more review the code as it is created. This helps

internal to the development team; they are catch errors in the code and improve it. actually peer reviews. Peers refer to those who Peers can be a valuable resource in

work on the same “level” as another. For example, software development.

two developers are peers.

Reviews can be formal, informal, involve detailed technical code analysis, involve high-level requirements design, etc.

In this module, the following types of reviews are covered:

• software walkthroughs
• software technical reviews
• software inspections
• requirements technical reviews
• requirements inspection

These reviews focus on creating better software, although there also exist reviews that are more management focused. These management-focused reviews are not covered here.

It is of note that review meetings should not be confused with other kinds of meetings that have different goals, like elicitation meetings (see the Client Needs and Software Requirements course). Review meetings focus on improving products and processes already in progress, while elicitation meetings are meant to help identify client needs at the outset of a project.

Software Walkthroughs

Software walkthroughs are the least formal of all types of software peer reviews. In a software walkthrough, the developer provides a short “show-and-tell” for a small audience of peers. Basically, the code is demonstrated, and during the walkthrough, peers are allowed to ask questions or point out potential issues. Software walkthroughs tend to be quick with the focus being on major issues; the minor issues are often skipped over.

Software walkthroughs tend to be informal because they are quick, easy ways of helping the developer improve the quality of the software. No work product is expected to come out of a walkthrough.

When reviewers watch the code demonstration, they check:

• for reliability of the code
• the security of the software
• the readability of the code
• that the code meets the team’s coding standards

There are many advantages to software walkthroughs. As outlined above, they are a good technique for harnessing the power of peers, and they allow suggestions and improvements to be quickly applied to code. Additionally, they provide the developer’s peers with the opportunity to learn about the feature’s code. This knowledge can be used to enhance other projects that the developer’s peers might work on in the future. Software walkthroughs are therefore also a good way to train new team members.

Software Technical Review

Software technical reviews are more formal reviews than software walkthroughs, although the level of formality used can vary depending on the organization implementing the review and the organization’s goals. For example, military companies are likely to use software technical reviews in a much stricter manner than a mobile gaming company.

As the name suggests, software technical reviews specifically address technical aspects of the product. Because of the technical focus, software technical reviews are often used to create more robust designs or to form more well-defined requirements from a client. Of course, they are also used to make technical improvements in the code.

Software technical reviews are discussion oriented. There are three main roles for this review:

• The decision maker who sets the goals for the review and determines if those goals were met.
• The review leader who keeps the review orderly and on track.
• The recorder who documents the issues identified over the course of the review. A recorder therefore does not take “meeting notes” but instead makes notes about the

findings of the meeting.

One person can have multiple roles in a software technical review. For example, a decision maker can also be a recorder. Reviews may also be attended by other development team members and contributors.

Before the review begins, all participants must prepare in some way:

• The decision maker creates a list of objectives for the meeting.
• The review leader makes sure that participants have access to the software product being reviewed.
• Other parties must review the material.

Once the review meeting starts, the review leader facilitates the conversation between all relevant parties. The goals for the meeting may cover issues such as technical processes, resolving ambiguities, creating more efficient code, improving the production process, improving or creating new requirements, etc. By the end of the meeting, the goals outlined by the decision maker should be met, and a list of recommendations should be created to address those goals.

Software Inspections

Software inspections are the most formal type of review discussed in this module. They are also known as “formal technical review.” Software inspections follow rigid structures and involve multiple roles. The goal of an inspection is to find and fix defects in some work product, such as a set of requirements or a module of code.

The roles in a software inspection are:

• The author who created the work product being inspected.
• The moderator who oversees the inspection and ensures it goes smoothly (the moderator is similar to the review leader in a software technical review).
• The reader who reads the document to the inspectors.
• The inspectors who point out defects in documents.
• The recorder who take notes of the major findings in the meeting.

One person can have multiple roles in a software inspection.

Software inspections also have multiple stages. Sometimes, some of these stages are repeated until the work product is deemed to meet appropriate standards by the team.

In general, strict procedures apply for determining if a stage is finished. For example, each stage might have a checklist that needs to be completed before the review can move on to the next stage.

The stages of a software inspection are:

The rework and follow-up stages are the most likely to be repeated, especially if it is found that not enough work has been done to address identified defects. Such cases are generally recognized in the follow-up stages. The author goes back to finish work, and another follow-up is performed, until the work product meets desired standards.

Requirements Technical Review

Requirements technical reviews are popular techniques used to ensure high quality requirements. They help to make sure the product is done right.

The roles in a requirements technical review are:

• Reviewers who try to identify as many defects as possible in a set of requirements written by the author. Ideally, reviewers are not part of the project. Distance from the project makes it easier for reviewers to determine if there are issues with the requirements.
• The author**(s)** who created the requirements being reviewed.
• The moderator who is responsible for making sure the discussion meeting stays on topic and that criticism is presented in a way that does not feel like an attack on the

author.

• The recorder who makes notes on the important findings of the discussion meeting. These notes will help author(s) to fix identified issues.

The role of moderator is one well suited to Scrum Masters, as they already moderate other meetings in a similar way. As well, the recorder does not necessarily need to be someone on the project. More than one reviewer can be involved in conducting the review at a time, alongside the development team.

There are two main stages to a requirements technical review. These stages are the review stage and the discussion meeting.

In the review stage, reviewer(s) go over a set of requirements written by the author(s) in order to identify as many defects as possible. This may include errors, omissions, etc., that would prevent the product from working. Sometimes reviewers are aided by a glossary or other important information sources.

Reviewer(s) also identify high-risk areas in terms of requirements criteria or any other related concerns. For example, requirements may be incomplete or could be improved in some way.

In a review, requirements are specifically assessed by reviewers against criteria as discussed in the Client Needs and Software Requirements course. This criteria suggests requirements should be:

• correct (each requirement represents what the client envisioned)
• complete (there are no missing requirements)
• clear (requirements are free of ambiguities)
• consistent (requirements do not conflict with one another)
• verifiable (requirements are measurable or testable in some way)
• feasible (requirements are able to be completed by the development team with the available resources)
• traceable (each requirement is connected to the associated design and implement artifacts in some trackable way)
• manageable (requirements are independent, meaning they are expressed in a way that allows them to change without excessive impact on other requirements)
• simple (requirements should be kept minimalistic and focus on one core idea)

Reviews may also go over requirements according to a set of guidelines that outline specific issues reviewers need to consider.

After requirements are assessed and defects are identified, reviewer(s) classify their findings by level of severity:

• major: when the repair for the problem is not obvious and a careful, further exploration is required
• moderate: when the repair for the problem is straightforward but needs to be reviewed further
• minor: when the fix for the problem is either unnecessary or obvious, and there is no need for further review

In the discussion meeting, the reviewer(s), the author(s), the moderator, and the recorder meet to discuss the findings of the review and reclassify the level of severity of those findings, if necessary.

Discussion meetings are generally advised to be time-boxed meetings, so they have a strict time frame that cannot be exceeded. This helps the discussion to stay on track and ensures that neither reviewer(s) nor author(s) lose too much time to this stage. Because of this, minor issues should take as little time as possible to go over.

In a discussion meeting, the author does not need to respond to every question or comment raised in the findings. In fact, the author is primarily at the meeting to better understand the issues and obtain clarification where needed, instead of there to address issues. The recorder, however, should make note of questions, comments, and findings. These practices help keep the meeting within the time box.

After the Requirements Technical Review process is a repair process. In this process, the author of the requirements uses the feedback from the review to adjust the requirements. Not all suggested changes are required to be incorporated into requirements because some changes may not be valid or have already been addressed. This is up to the author’s discretion.

Conducting a Requirements Technical Review helps to reinforce the concepts behind quality requirements and development.

Requirements Inspection

A requirements inspection is a specific type of software inspection. A popular technique, a requirements inspection is a formal process that helps ensure that requirements are clear, consistent, and complete. This makes the project more straightforward and easier to understand.

The roles in a requirements inspection are:

• inspectors who review the user stories.
• author(s) who created or help create the user stories. Product owners, software product managers, clients, and even development team members could all be authors.

During the inspection process, inspectors look for issues in the requirements, usually in the form of a list of user stories, against the criteria of:

• ambiguity
• consistency
• completeness (see Requirements Technical Review above, or the Client Needs and Software Requirements course)

Ambiguity in particular is an important issue to address, and third-party inspectors are often in the best position to identify unclear wording.

Once requirement issues are identified, the author(s) must fix them. The amended requirements are then presented in a follow-up.

Monitoring Issues

As you have seen, many different kinds of approaches can be used to monitor a project and track the progress, productivity, and quality of a work product, including velocity (see the Agile Planning for Software Products course), code walkthroughs, requirements technical reviews, etc. However, a number of issues also exist related to monitoring projects. For example, many projects skip metrics, and some metrics are not effective.

Skipped Metrics

Many software projects avoid measuring or using metrics at all. There are many reasons why metrics might be skipped, but it can be problematic if a project fails to identify issues that need to be caught and fixed properly. .

One of the most common reasons metrics are skipped is because of time. Developers have a limited amount of time to code, so any time spent on non-coding tasks, such as metrics, can be seen as an impediment on development. This issue is particularly complicated in an Agile framework. Agile focuses on fast and efficient development, so using metrics can sometimes seem like taking a step back for an Agile team. However, well-used metrics can prevent expensive mistakes down the road.

Metrics are also often skipped due to a lack of industry standards. Very few industry standards exist because many studies on metrics are inconclusive or cannot be generalized. Some studies suggest that metrics work better in certain situations or only for certain organizations. But there are many metrics to choose from, and since there is a lack of industry standards, it can be difficult to determine which metric is best to select and invest the time in for the project at hand.

The main issue behind skipped metrics is the lack of development of manager knowledge in this area, which often leads to the misuse or dismissal of metrics.

Ineffective or Misused Metrics

Why Are You Measuring?

Another common issue is the use of ineffective metrics. Often metrics are calculated, but they are not useful to the project or do not inform the project in any way. This misuse can lead to work that does not benefit the project, which indicates that there is a lack of understanding as to why things should be measured.

This can be well illustrated by the common metric in the industry, known as lines of code or LOC. This metric tracks the number of lines of code written for a piece of software. This number is then used to generate data related to the project. The data could include information such as the price per line of code (the cost of the project divided by the number of lines of code), or time per line of code (the average time it takes to write a line of code for the project).

Very quickly, however, it becomes apparent that this metric is problematic and unreliable. For example, different parts of the project, or even different projects can vary drastically from each other, leading to very different numbers of lines of code. Different programming languages can also influence the number of lines of code needed, even for the same feature. This makes it impossible to use lines of code as a means of assessing a project because circumstances prevent the numbers from being meaningful or comparable, even for the same coding language.

Metrics are also susceptible to misuse. For example, measurements can change a developers’ behaviour. Once a measurement is known, it is human nature to want to maximize the number. This can lead developers to write more lines of code than they would have if they had not known about the metric. Focusing on writing more can actually lead to a decrease in productivity, as the goal shifts towards creating quantity rather than on delivering the product. For this reason, it is important to understand why something is being measured.

Quantifying Everything

Metrics are rendered ineffective when they are used to quantify things that do not need to be. Sociologist William Bruce Cameron once Sometimes, it is tempting for projects using noted:

metrics to quantify everything. For example, you

could calculate the number of times the letter “a” “Not everything that can be counted counts,

and not everything that counts can be shows up in a piece of code, but this metric counted.”

would not improve the project and is not useful.

This phrase is a useful way of summarizing

It is important when using metrics to know that why it is important for projects to be

what you are measuring is important, and why it conscious of not over quantifying everything.

is being measured. Is the metric related to the

product in a way that is useful? Can it help improve the product? This way, the trade-off can be assessed between the value and insight the metric can provide the project and the time and other associated costs it takes to perform the metric. Measuring and monitoring a project can lead to improved software products and processes if it is done in a smart, informed manner.

Goal, Question, Metric (GQM)

Goal, Question, Metric (GQM) is a method of choosing metrics for software projects. It helps to ensure that the metrics used are measuring a part of the project that is valuable to the product manager and development team. In other words, it helps make sure metrics are used effectively on a project.

The GQM method was developed by Victor Basili from the University of Maryland in 1994. In his own words,

For an organization to measure in a purposeful way, it must first specify the goals for itself and its projects. Then it must trace those goals to the data that are intended to define those goals operationally, and finally provide a framework for interpreting the data with respect to the stated goals.

how to measure them. Objects might include:

The philosophy behind GQM begins with the idea that before you can be sure you are using the right metrics on a project, you need to understand what you want to measure first. This is the goal. Goals are generally used to improve objects. Objects in a software project can be classified into categories that help identify

• work products, such as code or documentation
• processes, such as testing or elicitation processes
• resources, such as office space, computers, salaries, work effort, etc.

Once you know what you want to measure, you must assess what defines the goal. In other words, what question do you need to ask to ensure the goal is being met? Questions should be specific enough that their answers address the goal. Another useful practice is to break down big questions into smaller ones that focus on specific facets of the goal. Together, all the questions should address the entire goal.

Only once the goals are defined with questions can you move on to implementing metrics and collecting data. The metric is the quantitative way to address the question asked.

The GQM method is similar to the process of eliciting requirements, which was discussed in the course Client Needs and Software Requirements. Many comparisons can be drawn:

In eliciting requirements, requirements must be discussed with the client so that needs and wants are clearly defined. They are not simply gathered. In GQM, you do not simply develop questions; instead, the goal of the metric should be well understood first.

In eliciting requirements, once the requirements have been identified and expressed as user stories, you do not build them right away. Instead, user stories are broken down into smaller, manageable developer tasks. In GQM, questions should also be broken down into smaller ones focusing on specific aspects of the goal of the metric, but when added together, the information addresses the entire goal.

When working with requirements, work in a software project should only begin once the tasks and user stories have been planned with a release plan and an iteration plan. In GQM, metrics and data can only be used once the goal and questions are clearly defined.

Although similar to metrics as described in other sections of this course, in GQM, metrics are made more valuable because of the planning process preceding their use. The questions the metrics are designed to answer were thought out ahead of time, which help to avoid issues of ineffective of misused metrics.

Metrics in GQM can be objective or subjective. Objective metrics are based on data that does not rely on any individual’s viewpoint or interpretation. They generally involve numbers, such as the number of downloads, sale numbers, processing time, the number of complete user stories, etc. Subjective metrics depend on interpretation, however, such as ratings or developer morale.

A simple example of the use of GQM helps illustrate the process. Imagine that a product has been created and released to the public, and you would like to know how satisfied customers were with the product. The goal in this case would be customer satisfaction. With the goal identified, a number of questions can be created to address the goal. For example, is the product reliable? Is the product fast? How do users rank their satisfaction? How many times do users engage with the product over a given period of time? From here, metrics can be identified to answer those questions. In this case, this might include defect density, response times, collecting customer ratings on a scale of one to five, or collecting data on the number of times the software is used.

TIP: Using the FURPS+ acronym can help you develop questions in GQM.

As a model by Robert Grady at Hewlett-Packard to classify software quality attributes, FURPS+ stands for:

• Functionality, where questions could be related to how well the product works, its security, or if it meets customer needs and wants
• Usability, where questions relate to effectiveness, aesthetics, the quality of documentation, etc.
• Reliability, where questions relate how the system reacts to failure, the accuracy of product results, etc.
• Performance, where questions relate to how quickly the product works, throughput, the memory consumption of the product, etc.
• Supportability, where questions relate how serviceable the product is, whether or not it can be configured, whether or not there is some means of monitoring the system, etc.
• Plus questions related to design constraints, implementation requirements, interface requirements, or physical requirements

Desirable Properties of Metrics

In order to use metrics that can provide trustworthy results, it is important to understand the desirable properties of metrics. The following key terms are properties that can be used to help identify what is a “good” or “bad” metric or, in other words, a metric’s desirable properties.

A measure is a standard or unit of measurement. Each unit is one instance of that measurement. For example, inches are a measure. “Inch” is a standard; each inch is a unit, comparable to another one. Without consistency, metrics cannot be meaningful.

A metric is a combination of two or more measures that provides a meaningful result. For example, kilometres per hour (km/h) is an example of a metric. Kilometres and hours are two measures that when combined are meaningful. Not all metrics are meaningful, since almost anything can be measured. For example, number of keystrokes per hour is not a helpful metric, because it does not necessarily provide any meaningful information about the project. Keystrokes are only loosely related to the creation of software—different programming languages may require more or less keystrokes to write out the same feature. Further, progress can still made on a project, even when little typing occurs, and vice versa—a large amount of typing does not necessarily mean progress was made on the project or that all the typing done by one person was one-hundred-percent project related.

An indicator is a measure that draws the attention of the person making the measurements. The value of the indicator informs the numbers in some way, which would be meaningless alone. For example, if a person’s oral temperature is between 36.5 and 37 degrees Celsius, this is an indicator the person is healthy. If their temperature is over this range, then it is an indicator that they have a fever. Indicators therefore also signify if there is something to be aware of in the measures or metrics.

As outlined in the lesson Goals, Questions, Metrics (GQM), the right metric will help answer the questions about the goal of the metric. Understanding desirable properties of metrics helps identify if the right metric has been chosen.

Although other abilities of metric might be seen as desirable, such as reducing hours, this is not considered a broader desirable property of metrics. It is actually a goal of metrics because it a measurable outcome, instead of a property, which is more of a quality of a metric.

An example of a good metric is the number of defects found in a product per week. This is a simple calculation, as all that must be done is track the number of defects reported in a week through bug reports or logged issues and then add them up at the end of every week. It is intuitively persuasive because defects are clearly negative and decreasing defects creates a better product. It is a consistent metric across units and programming languages, because assuming developers are about equally skilled in one language as another, the number of defects per week should remain fairly consistent across different languages. It is an objective metric because defects in code are not based on someone’s opinion—a logged defect is an issue that must be addressed. It is also an effective mechanism for improvement. Tracking defects each week over time should allow you to see if defects are increasing or decreasing as the project progresses. If processes are used to help increase code quality or the number of defects that can be fixed, then the number of defects per week should decrease over time, and the product should improve.

Number of defects per week is a metric that also provides the added bonus of being scalable to specific parts of a product, as well as applicable to the product as a whole. Problem areas can then be focused on, if desired.

It is important to remember that metrics are not always absolute; they may be relative only to a specific project. For example, velocity (see the course Agile Planning for Software Products) is the metric of story points per sprint. Story points are relative estimates that can vary from project to project. Using relative metrics is fine, as long as you remember that two metrics based on slightly different measures are not a hundred percent comparable. Velocity for one project cannot be compared with the velocity of a very different project.

Popular Metrics to Improve Software Projects

This lesson focuses on popular metrics that are used to assess the product and project based on non-functional requirements, so the goals for the metrics discussed in this lesson are based on non-functional requirements. Non-functional requirements are those that describe how well a product must perform (see the course Client Needs and Software Requirements). They are also known as quality requirements, which addresses issues such as accuracy, dependency, security, usability, efficiency, performance, and maintainability.

Metrics generally become popular if process is involved. This means they are able to provide insight into improving the process of creating the product.

Goals for metrics according to non-functional requirements and the popular metrics associated with them are explained in the table below.

Other aspects of a product can be measured too, such as correctness. However, this is expressed more through functional requirements. Correctness is often measured using defect analysis, which is explored in the following lesson.

A number of popular metrics were outlined above. There also exist unpopular metrics, which fail to offer improvements to the process used in the project. These might include lines of code delivered, size of documentation, etc.

The McCabe number, part of the metric known as cyclomatic complexity, is another example of a metric that can be used to indicate the complexity of a program. It is a measure of the number of logical branches there are in a product’s source code. This is a very code-specific metric, so more details extend beyond the scope of this specialization, but it is still worthy of mention.

Defect Analysis

Defect analysis is a way to assess the quality of a product by analyzing the number of errors in the product. An error is something that fails in the product. Often product errors are associated with the source code, but errors can also occur elsewhere. Defect analysis a common tool in the industry, and it is considered one of the most useful.

Traditionally, defect analysis is performed by tracking the number of defects in the code and comparing that number to the amount of defects that have been fixed. The number of defects can be found by adding up all the errors reported in the system. These reports may come from testers before the product is released, known as pre-release, or users after the product is released, known as post-release. There are also many tools available that can help track bugs and other errors, as well as updates on whether or not those issues have been addressed.

The number of errors can then be tracked and compared over time. The rate of defects found is compared to the rate of defects fixed. These numbers can serve as an indicator of whether or not more focus should be placed on fixing current problems instead of creating new features. If more bugs are found than fixed in comparing the two rates, then more work needs to be done to fix problems. Consequently, the number of defects fixed should rise. This serves as a means of tracking improvement. Over time, the number of defects fixed should increase, and fewer defects should be found.

When the number of defects created and found is the same as the number of defects fixed, this is known as a software barrier. Once this software barrier is reached, it also indicates a need for change in the project. More time should go into fixing bugs, just like when the number of errors exceeds the number of fixed defects. It also means the product is not ready for release.

Subsystems

Defect analysis can also be performed on subsystems. Subsystems are different components of a product that usually have a specific purpose. Together, subsystems make up a whole system. In order to determine defects in subsystems, each subsystem associated with a defect must simply be noted. This applies for both defects found pre-release and post-release. Once defects have an associated subsystem, the numbers can be tallied for each subsystem. Subsystems with more errors will likely need more attention. It should be noted, however, that a fair comparison will need to normalize for subsystem size, since bigger subsystems will have more defects due to their size.

Defect Density

Defect analysis can also be performed using the metric of defect density. Defect density operates under the idea that rigorous testing and revision can bring a product closer to a perfect status. In order to calculate defect density, the ratio of the number of defects found in the source code is compared against the size of the code. The size is measured in “thousands of lines of code.”

Defect density is the standard way of determining how any defects the product has as a whole. The industry average for defect density is between 15 and 50 defects per thousand lines of code.

Defect density can be used to help determine if a product is ready for release. This is because defect density can be predicted based on the defect density of previous releases.

For example, imagine you have created a product with two previous releases. You are trying to determine if the current and third version of the product is ready for release using defect density.

In the first release, 900 defects were found pre-release, and 100 defects post-release in a total of 100,000 lines of code. The first release therefore had a total of 1,000 defects per 100,000 lines of code, or 10 defects per thousand lines of code.

In the second release, only 400 defects were found pre-release, and 45 defects post-release, in an added 50,000 lines of code. A total of 445 defects were found. The defect density is therefore 8.9 defects per thousand lines of code.

In the third version, 100,000 lines of code was added to the product. 600 defects have been detected so far, so the current defect density is 6 defects per thousand lines of code. Although this number seems smaller than the previous two releases, the product is still not ready for release. In the previous versions, 90% of defects were found in pre-release. Unless a significant change has happened in the development process, the 600 defects found in this version should also represent 90% of the overall errors in the code. This means you should expect to find another 120 to 255 more defects. It is best practice to find defects before a product is released, so an effort still needs to be made to find those remaining errors.

Subsystems with high post-release defect numbers can be improved through more pre-release testing, or by bringing in more senior developers to work on the team, who have more experience to catch these problems.

DID YOU KNOW?

One famous example of defect analysis is that of the space shuttle flight software developed originally by IBM. This software is famous for being error-free. When IBM developed the software, it did not just fix defects that were found, the defects and the circumstances surrounding it were also analyzed. Then, similar areas where the defect could happen again were identified and tested. Further, the entire development process was adjusted to prevent similar defects in the future.

You can read more about defect analysis in the Course Resources.

Managed Right

**Upon completion of this module, you should be able to: **

• Explain the scrum process of the daily stand-up meeting and the three questions of the stand- up (what did you do?; what are you going to do?; what is blocking you?).
• Map out and explain estimated velocity against actual velocity.
• Explain how to predict velocity.
• Recognize how velocity is an Agile practice and that velocity changes depend on factors such as learning curves, bugs, risks, etc.
• Define the term velocity driven.
• Create and describe a release burndown.
• Define the term burn up, and burn down.
• Create and describe a total work done release burndown and an adjustable floor, and how these can be used to demonstrate changes in requirements and actual velocity.
• Create and describe an iteration burndown, which is generated daily
• Summarize the concept of a whiteboard task board and how to create an iteration burndown from the task board.

Stand-ups

Daily Scrum

The previous two modules focused on the software development goals of producing the right product, and ensuring the product is done right. This module focuses on the software development goal of managed right, which includes keeping a project on schedule and ensuring development is effective and occurring at a

sustainable pace. DID YOU KNOW?

Scrum

This lesson examines the process known as The Daily meeting is also known as a Daily Scrum. The Daily Scrum is a daily daily stand up, a daily huddle, or morning meeting that occurs with the development roll-call. This lesson will use Scrum team, usually at the beginning of the day. It is terminology.

meant to synchronize the development team.

Daily Scrum is what this meeting is called in Scrum methodologies. However, this type of meeting is common to many other methodologies as well. In Extreme Programming (XP), this meeting is known as the daily stand-up. XP is a software development methodology that provides practices for management and development.

Daily Scrums are usually attended by developers, the Scrum Master, and any other interested participants. The Scrum Master is the role in Scrum who organizes and facilitates the development team and Product owner (or client). Other interested participants might include developers from other teams, business executives interested in a project update, or Product owners. Product owners are not required to attend every daily Scrum meeting, however.

This meeting usually occurs at the same time and place each DID YOU KNOW? day. Often, development teams choose to hold the meeting in

Kanban was developed by front of a task board or a Kanban board, so teams can update the automotive company their progress at the same time as the meeting. Kanban is a scheduling system that organizes production in a logical chain.

Task boards are discussed more in the Sprint Monitoring lesson of this module.

Importantly, the Daily Scrum is a time-boxed meeting. This means the meeting has a strict time limit that has to be observed.

During the Daily Scrum, meeting participants stand up in a circle and each person answers three questions:

1. What did you accomplish yesterday?
2. What will you do today?
3. Are there any impediments in your way?

DID YOU KNOW?

In a Daily Scrum, usually meeting members who are substantially committed are nicknamed pigs. Other meeting members who do not contribute to the project in the same way do not speak, and are nicknamed chickens. These nicknames come from the same joke!

The joke goes like this. A pig and a chicken are talking, and the chicken suggests the two start a restaurant. The pig agrees and asks what the restaurant should be called.

“Bacon and eggs?” suggests the chicken.

“No, thanks,” answers the pig. “I’d be committed, and you’d only be involved.”

These nicknames are a handy way to remember in Scrum who is committed to the project, and who is only involved!

To ensure the meeting stays within 15 minutes, often only the people who are substantially committed to the project answer these questions, such as developers and Product owners if they have a major update.

If the conversation during the Daily Scrum starts to go off topic, it is the responsibility of the Scrum Master to cut the conversation short. The “stray” topic is then added to a list of issues to discuss after the meeting is over or at the beginning of the next meeting. In the case of moving the discussion to the end of the Daily Scrum, those involved with the “stray” topic, or who have interest in it, are invited to wait until after the meeting to continue talking This practice helps to keep the Daily Scrum to 15 minutes, while still encouraging open communication. The list of topics to discuss is commonly known as a

parking lot, a sidebar, or is referred to as discussing offline.

It is important that even if there is extra time in a meeting before 15 minutes is up, off-topic discussions should still be ended and moved until after the meeting or to the next meeting. Even if there is time in a short meeting, ending off-topic discussions reinforces focused conversations for future Daily Scrums.

The Scrum Master is also responsible for recording impediments brought up in the meeting that were not resolved. The Scrum Master has to make sure these impediments are resolved or that someone is assigned to resolve them.

The end of a meeting should be signaled by some kind of action. This symbolizes a clear end to the meeting and prevents people from lingering or wondering if the meeting is over. Catch phrases or team cheers are actions commonly used to signal the end of a meeting.

It is important to understand that Daily Scrums are synchronization meetings. They are for the benefit of the development team, encouraging communication and commitment from team members to one another. This means that Daily Scrums are not the place for suggesting improvements, nor are they status meetings where members simply report their progress to their superiors. Tracking progress is covered by practices such as Kanban boards or iteration burndowns instead.

In a Daily Scrum, the commitments from team members to each other means that the team should expect goals for the day to be met and reported at the following Daily Scrum. If goals were not accomplished, some impediment should explain why, or the team should offer to help somehow. These kinds of practices reinforce the team nature of Daily Scrum.

Daily Scrums should also be an enthusiastic meeting that makes team members excited to work for the day. Using the practice of Daily Scrum improves team support and a sense of teamwork, encourages work, and open communication. This makes Daily Scrum a good starting point and introductory practice for companies and teams interested in bringing in Agile practices into the workplace.

Common Issues in Daily Scrum

Starting the Meeting and Order of Speakers

There are a number of common issues that can come up in the use of Daily Scrums. The most common occurrence is that no one wants to start the meeting or knows the speaking order. In these cases, the team usually looks for direction from the Scrum Master.

Although the Scrum Master might call the meeting together, it is important that they do not always start it. If the Scrum Master always starts the meeting, Daily Scrums run the risk of becoming status meetings.

A good strategy to use is last arrival, speaks first. This means that the last person to arrive at the meeting is responsible for starting it. This strategy encourages punctuality, so it is also good to use if team members are frequently late. However, sometimes the last person to arrive at Daily Scrum is the least prepared to speak, so this strategy can have problems.

Some teams make use of a token that they pass around instead. This means that a token such as a ball, plush toy, or some kind of office supply is passed around. The person with the token speaks and then he or she passes the token to another in the circle who then speaks. Participants are more likely to pay attention in a Daily Scrum with this strategy, and it solves picking who speaks next in the meeting.

Another strategy to deal with this issue is the round robin. In this technique, one person volunteers to start the meeting and then the meeting goes around the circle from that person in one direction, with each person giving their update where applicable.

Exceeding the Time Box

Another common issue encountered in Daily Scrums is that the meeting exceeds the 15-minute time box.

One strategy, suggested above, is making sure just the “pigs” of the meeting speak. The Scrum Master should also be sure to add off-topic conversations to the parking lot.

Another helpful practice is to make sure the team is actually standing for the meeting. People who are standing are more likely to engage in quicker conversations and they are less likely to hang around after the meeting is done. If meetings still go over 15 minutes, then a modified pass-the-token technique can be helpful. Instead of using a small token, a heavy exercise ball should be used. Holding the ball will encourage participants to be concise and pass the ball to the next person. If necessary, participants can also hold the ball with their arm stretched out in front of them, making it even harder to hold, which encourages even faster meetings.

Lack of Impediments

Sometimes Daily Scrums encounter problems when no one brings forward impediments at the meeting. This is especially problematic if deadlines are missed, but no impediments are listed, as it becomes difficult to know why development is affected.

In order to counter this problem, the Scrum Master can include impediments in their own updates, which may encourage others to discuss theirs. The Scrum Master can also ask questions at meetings, such as “Is there anything that I, or the team, can do to make your day easier?” Remember, the Daily Scrum should not feel like an attack; it should be a team effort.

Team Members’ Schedules

In work environments that offer flexible hours, a common problem for Daily Scrum is that not all the team members are present in the morning. In these cases, the Daily Scrum needs to be held at later time in the day, but one that does not make it feel like the start of the day has moved later, which can lead to lost work hours. A good alternative time is after lunch, so the Daily Scrum still feels like it is in front of a block of work.

Becoming a Status Meeting

When holding Daily Scrums, it is important to be careful that the meetings do not begin to turn into status meetings. In status meetings, members just report to the Scrum Master or the Product owner and not to the rest of the team. A good rule to avoid this is to ask the person speaking to not look at the supervisor, so it forces people to look at other team members and engage with them more.

See the Course Resources for a list of tips for holding Daily Scrum meetings!

Velocity

The concept of velocity has already been described in the course Agile Planning for Software Products, but it is reviewed in this lesson as a metric used to manage a project right.

Velocity is the measure of the number of units of work a team completed within a time interval. Software projects commonly use story points completed per sprint as a measure. In fact, velocity should work at the level of the user story and not tasks, which make up user stories.

Velocity can be calculated as an estimate or an actual number. An estimated velocity sets a “goal velocity” for the sprint, while the actual velocity is determined by how many story points were actually completed in an iteration. In both cases, it is very important that a user story is done before it can count towards actual velocity. This means that the work product or task should not only be developed but verified through testing.

Estimating velocities is not always an accurate endeavour. In ideal situations, the same development team has worked on a similar project in the past, so it can use this as a basis for new velocities. However, the development team does not always have such previous experience. In those cases, velocity can also be estimated by taking the user stories that are planned to be completed in a sprint and creating a work breakdown structure (WBS).

A WBS is a representation that takes one large work product or task and breaks it down into smaller, manageable work products or tasks in a hierarchical fashion. Each of those small tasks is easier to assign an estimate, and then those estimates can be added together to make an estimate for the sprint. If the estimated time does not match the amount of time the development team has available, then user stories may need to be added or removed from the sprint. Once all the user stories have been decided upon, their totalled story points will be the estimated velocity for the sprint.

Actual velocities may vary for each sprint as well. This usually happens at the beginning of a project, when the development team is still learning to work together or with new technologies. Over time, however, velocities should stabilize. A development team following the Agile principle of maintaining a sustainable development pace should have a stable velocity.

Actual velocity is also used in the creation of release and iteration burndowns, as explored in the following lessons.

Release Burndown

A release burndown chart is a visual monitoring technique common in Scrum. It helps ensure a product is managed right.

There are many advantages to using a release burndown chart. Release burndown charts allow an entire development project to be visualized, including:

• How much work the development team has completed
• The work left to finish
• The actual velocity of each sprint
• When the product is expected to be finished

Release burndown charts can also provide early warning that a project is going off plan. However, in spite of providing all this information, release burndown is still a straightforward concept.

Here is a simple example of a release burndown chart:

Each bar in a release burndown chart shows the total number story points remaining at the beginning of a sprint. Sprints are listed horizontally—in the example above, there are six sprints. The vertical axis represents total effort. This should be in the measurement the development team has decided to use to size requirements, like hours. In this lesson, story points are used.

Sprint 1, or the first bar, has all the story points remaining to be completed. This is the total effort, or the combined total of the story points for all the user stories intended to be completed in the project. As requirements are completed, their story points are removed from the burndown chart, so the next sprint does not include the finished story points. This is illustrated in the example below.

In this example, the total effort for the first sprint was 90 story points. During Sprint 1, 15 story points were finished. These points were taken off in Sprint 2, so that 75 points remain.

Once two or more sprints are available, release burndown charts can be used to make predictions about how many sprints it will take to finish the project. This is done using a prediction line, which is a line drawn through the middle of the top of the bars. This is illustrated on the next page.

This prediction line shows that this project will take six sprints to finish. Even though the line ends at Sprint 7, that sprint actually starts with zero story points (remember the bars represent story points remaining), so Sprint 7 does not need to happen.

Prediction lines help development teams determine if project development is on track. This is illustrated in the example below:

In the example, 15 story points were completed in Sprint 1. A prediction line was generated that suggested that 15 points should be finished in Sprint 2. However, only 5 story points were completed, and Sprint 3 started with 70 points. This is above the prediction line. In Sprint 3, 15 story points were completed again. Velocity was back to its initial value, but the project was still behind schedule at the start of Sprint 4.

If this happens, projects will sometimes hire developers to help get a project back on schedule.

In this example, after extra developers were brought TIP: Release burndown charts almost onto the project, 25 story points were finished in never perfectly follow the prediction Sprint 4. This put the project back on schedule. If line. The first simple example chart in the team maintains a velocity of 25 story points per this lesson follows a prediction line sprint in Sprint 5, then the project will actually be perfectly. In real life, however, release ahead of schedule, as Sprint 6 will begin with only 5 burndown charts are more likely to look story points, as illustrated above. In this case, extra like the example chart immediately requirements can be added to meet the prediction above this tip.

line.

The definition of done is very important for release burndown charts, because the release burndown only measures completed story points. In order for story points to be complete in Agile, which measures progress with working software, the development team must decide upon a definition of done, and only user stories which meet this definition should be considered done.

In cases where many requirements are worked on at once but are not completed over several sprints, release burndown charts will look like the example below.

In this example, it took until Sprint 4 for requirements to finally reach the definition of done. At first glance, it might look like nothing was worked on for three sprints, and then a lot suddenly done in the fourth, even though this is not necessarily true. A release burndown chart can therefore inform a team if they are starting too many new tasks before completing old ones, and whether or not tasks are truly being completed. The chart focuses on “done” stories, to depict the real progress.

Changing Requirements

In Agile, change is an expected part of software development. Requirements change constantly, with new ones added, or estimates for story points might change for a requirement. Although it might be tempting to just add story points to the basic bar charts shown in this lesson, this can give a false representation of how much work was done. If 15 story points were finished, but 10 are added, it might look like only 5 story points were completed in a sprint.

There are two ways of showing change in a release burndown chart.

The first shows the total amount of work in each sprint, by adding bars above the work remaining bars. This is illustrated in the example below.

The bottom bar represents the work remaining, as before. However, a bar is also added on the top, representing completed work. In this example, the number of story points in the project has remained the same from Sprint 1 to Sprint 2, and completed story points are represented in turquoise at the start of Sprint 2. In Sprint 3, however, 10 story points were added. This is visible in the chart, because the bar is now taller than the original total effort bar. In Sprint 5, story points were removed, resulting in the sum of the total amount of work remaining and work completed as smaller than both the sprint before and the total effort at the beginning of the project.

This system therefore shows the team’s actual velocity, as well as any changes in story points. When calculating actual velocity, it is important to remember to take into account any story points that have been added or removed, as well as the number of remaining story points. This is illustrated in the example on the next page.

In this example, Sprint 2’s velocity is 5 points. The number of remaining story points went from 75 at the beginning of Sprint 2, to 65 at the start of Sprint 3. This makes it seem like 10 story points were completed, and the sprint velocity was 10 story points per sprint. However, the top bars indicated that 5 story points were removed from Sprint 2 to Sprint 3. These points must be subtracted from the 10 story points that seemed to have been completed, making the velocity 5 story points per sprint.

The second way of showing change in story points in release burndown charts is by using an adjustable floor. This demonstrates a change in story points on the bottom of the chart, instead of by adding a bar on top. This is illustrated in the example below.

In this example, parallel to the example above with added bars, new story points are added in Sprint 3. The bar in Sprint 3 is extended below the x-axis. In Sprint 5, story points removed, and the bar is then made higher than the previous sprint.

Prediction lines should also be adjusted to align with adjustable floors. This is illustrated in the example below.

In this example, since the “floor” has moved below the x-axis, the prediction line should also stretch to the same level. This project should take six sprints to finish.

In general, the basic form of release burndown charts is a good tool to for projects that wish to show how much total work is left to complete. It is also used when tracking velocity is not necessarily important to the project. However, in cases where the development team would like to track more information, such as changes in story points, or the actual velocity, using total work done release burndowns or adjustable floor release burndowns is better. However, these last two techniques are fairly interchangeable, so it is up to team preference on which to use between the two.

Release Burndowns as Line Charts

Sometimes release burndowns are drawn as line charts instead of bar graphs. This is illustrated through examples below.

Simple charts from a bar graph to a line chart will appear as below.

Total work done release burndown charts from a bar graph to a line chart will appear as below.

Adjustable floor release burndown charts from a bar graph to a line chart will appear as below.

Sprint Monitoring

Burndown charts discussed in the previous lesson were used at a release level. However, they can also be used at an iteration or sprint level. These are known as iteration burndown charts. An iteration burndown chart is illustrated in the example below.

As with release burndown charts, iteration burndown

charts have a prediction line that demonstrates what TIP: It is helpful to consistently use sustainable completion of tasks should look like. baanrd grapline chsha for rrts felor ieatseratie buonrndowns,

burndowns, or vice versa. This Iteration burndown charts can be line graphs or bar makes a chart easily distinguishable

graphs, just like release burndowns. It is a matter of as the release level or iteration level preference for which type of chart the team will use. at a glance!

Below is the corresponding bar graph for the line graph example above.

In an iteration burndown chart, the horizontal axis represents days, while the vertical axis represents total effort, usually in hours. An iteration burndown tracks the completion of tasks, instead of user stories and story points as done on the release level. Remember that user stories are made of several tasks. This means the bars or points on the graph represent the total work remaining at the beginning of each day.

The dates listed along the horizontal axis represent the working days of the project. Weekends, holidays, and other days taken off of work are not included, unless work is scheduled on those days. In the example above, you can see that the chart goes from February 26 to February 29. This means no work was done on February 27 or 28, which may have been a weekend. Non- working days are simply skipped in the chart.

Iteration burndown charts should be updated daily. This is typically done during the Daily Scrum, when the previous day’s work is plotted as updated in the meeting.

When the iteration burndown chart is updated, this usually corresponds to an update with a Scrum task board, also known as a whiteboard task board, or a task board. A Scrum task board is similar to a Kanban board—it is a means of tracking progress. A Scrum task board is illustrated on the next page.

In a Scrum task board, user stores that are intended to be completed are written on post-it notes and placed in the first column, as seen the example above. Then, each user story is broken into developer tasks, and estimates are created for those tasks. These are also written on post-it notes.

Developers will often write their name on a task as well, after they have been assigned the work. This helps the project track who is doing what, and it makes it easier to identify who to talk to about certain tasks.

Tasks can then be placed in a number of different categories on the board, according to what stage the task is in and in the row of the user story they belong in. Task board categories are:

• To-do
• In progress
• To verify
• Verifying
• Done

As tasks are finished according to those stages, they move across the task board into their appropriate categories, similar to a Kanban board. This is illustrated in the example below, with the dotted arrow that shows the movement of one task (or post-it note) across categories.

Once a task is “done,” then it is complete and can be “burned” on the iteration burndown chart when it is updated during the Daily Scrum the next day. Hours are “burned” by being deducted from the total effort remaining on the chart. Only tasks that are completed are included in the iteration burndown.

After all the tasks for a user story are in the done column, then the entire user story should meet the definition of done.

A task board is helpful to use alongside an iteration burndown, because it clearly shows what tasks are completed and verified, and can be “burned.”

For example, imagine three tasks were finished on day 6 of a sprint.

On day 6, the arrow points to 40 hours. Since 25 hours were completed on day 6, the arrow would move to 15 hours on day 7. This is how a task board can help inform an iteration burndown chart.

Adjustable floor charts and total work done iteration burndown charts are likely not necessary in most iteration burndowns, although if desired, these can be easily implemented. Iteration burndowns focus on providing a visualization of the development team’s progress within a sprint. They are not used to calculate velocities like release burndowns are, so removing or adding tasks does not have a big impact on information portrayed.

Iteration burndowns can help a team realize quickly (within a day or two) if they are off target, however. This is very useful, as it is better to know mid-sprint than at the end of the sprint that things are not going right. This is primarily realized through two different processes that can show up on an iteration burndown chart: burning up and burning across.

Burning up happens when more tasks are added to a sprint than are completed or removed. This results in remaining work hours increasing over time, instead of decreasing. This is illustrated in the example below.

Burning up usually happens when the team did not do careful iteration planning. User stories were not carefully broken into appropriately sized tasks, or some tasks were overlooked or forgotten. This can be problematic, especially late in a sprint, since it means that tasks may not be completed. One of the best strategies to deal with this issue is to remove or prioritize some tasks. This helps ensure that tasks are not half done at the end of the sprint.

Burning across happens when the team is not completing tasks. This results in remaining work hours staying consistent over time, instead of decreasing. This is illustrated in the example below.

Burning across usually happens when the team is:

• Adding as many tasks as it is completing or removing.
• Not working towards the full completion of tasks, although they may still be working.
• Not working at all.

The second scenario is the most common. One of the best strategies to deal with this is to have a meeting with the development team, where emphasis is placed on completing tasks before starting new ones. It should also be suggested that team members with free time should help someone else finish a task, instead of starting something new. This helps avoid having half- done user stories at the end of the sprint, which cannot count towards burndown.

Iteration burndown charts are useful tools for assessing quickly what might be going wrong in a project and how to fix it. They ensure a project is managed right on a day-to-day basis.

Project Retrospectives

**Upon completion of this module, you should be able to: **

• Explain the terms: retrospective, postmortem, and lessons learned.
• Summarize what a retrospective is used for.
• Recognize that retrospectives address both what went wrong and right.
• Explain what a safe environment is and how to create it.
• Explain the difference between a functional and non-functional culture.
• Describe the role and benefit of an outside facilitator.
• Summarize how to prepare a retrospective.
• Identify what happens at the beginning, middle, and end of a retrospective, and list steps of a retrospective meeting, including the readying course, past course, and future course.
• Explain examples of retrospective exercises in a project retrospective, at the readying course, past course, and future course.
• Identify good questions an outside facilitator could ask in retrospective exercises.

What are Retrospectives?

Retrospective is a term that describes the act of reflecting on work done, or not done, over the course of the project. This reflection examines what went well and what did not go well in the work. Usually, retrospectives lead to a set of improvements.

This module covers two different types of retrospectives:

• sprint retrospectives
• project retrospectives

Sprint retrospectives have been touched upon before in the course Agile Planning for Software Projects with respect to time boxing and iteration planning. Both those practices involved breaking up time into small, manageable pieces in which work can be accomplished.

In Agile methodologies, it is recommended to have a planned self-appraisal session at the end of those time-boxed iterations. This self-appraisal allows insights to be applied to the following iteration or sprint, allowing the project to improve. This self-appraisal is the sprint retrospective.

Project retrospectives, also known as postmortems, are team reviews of the entire project after it is complete, instead of just a review of a time-boxed sprint. This means that although project retrospectives also examine what went well and what did not, as well as identify how the project could be improved, there are no “next sprints” to apply these lessons learned from a retrospective. Lessons learned are insights the development team has discovered through reflecting on the work done and how it could be done better the next time.

Project retrospectives can be applied to future work that people on the development team might participate in, whether together on the same time or not.

Retrospectives also allow the development team to address any personality differences, disagreements, or compromises made over the course of the work. If such issues are discussed in a collaborative, open atmosphere, without judgment, then teams can release energy and mend any differences.

The members of development teams are responsible for selecting what is important to discuss and what should be focused on in a retrospective, so the team feels they contribute to their own improvement. This increases motivation without external forces pushing the team to improve.

Sometimes, retrospectives are avoided. In such cases, the development team is likely to go ahead and start planning the next sprint and then jump directly into development. However, without retrospectives, there is little sense of what is going well or not well in a project. Further, even if team members voice concerns without retrospectives, there is no official way to capture these feelings about the project and channel them into structured change in a project (or not, if the team decides upon reflection that things are better as is). Retrospectives should always be encouraged, because there is always room for improvement in a project.

Retrospective Issues

There are a number of issues a development team might face regarding retrospectives. Often, a team may decide to skip retrospectives. This can be for many reasons, including:

• lack of time
• a desire to look ahead instead of reflect on the past
• some people may not like to speak about themselves
• some people may be burned out and wish to move on from the project

Sometimes, retrospectives are carried out for the wrong reasons, like being required to do one for an audit.

Feeling Safe

The most common reason retrospectives are not implemented properly, however, is that the development team does not feel safe enough to participate in reflective discussion, either emotionally or professionally. Feeling safe refers to a person feeling as if they can express themselves in a genuine and truthful manner without fearing a negative response from peers or management. In other words, people feel safe when they can communicate openly without judgment and if they are supported regardless of what they have to say.

For example, imagine a developer named Pierre is working on a software development project with a team. For the past few days he has been unproductive due to burn out. In an environment where he feels safe, he can express this openly in the Daily Scrum. On the other hand, in an environment where he feels unsafe, Pierre might try to embellish his work to make himself seem more productive, because he is not comfortable expressing himself.

As the example above helps illustrate, it is important that team members feel safe. If they do not, important issues may be ignored and cannot be resolved. In Pierre’s case, if no one knows he is burned out, then it will be hard to help him. Pierre will remain unhappy, and his productivity may lower still.

Here are some major techniques software project managers can use to help create safe environments:

• Let the team know that the retrospective happens in an open environment, where new ideas and perspectives are encouraged.
• Show appreciation for contributions made by team members. Feedback in the form of appreciation lets team members know their input is valued. Often, when no feedback is given, people will assume input is not appreciated. Project managers should remember that this doesn’t mean they have to agree with the contribution, but they should still acknowledge that contributions are valuable. There are several methods managers can use to show appreciation by:
• telling each person directly their input is appreciated. However, if not done well, this method can seem insincere.
• encouraging feedback when the manager themselves offer perspectives and ideas. This helps team members feel comfortable giving feedback in general and to other members.
• building or expanding on another team member’s idea, and then attributing the original idea back to the person who thought of it. This provides validity to the idea and affirms the person who thought of it.
• Show positive leadership. This means the manager should be a role model for the team by showing appreciation and having a positive attitude. As mentioned before, managers should always show team members high levels of respect even if they do not agree with the idea presented.

Returning to the example above, if Pierre reveals he has not been productive lately, the manager should not chastise him, or the environment may no longer feel safe. Instead, the project manager should express appreciation towards Pierre, especially since he is being brave. They could also suggest that Pierre take some time

away from his current problem to refresh his mind, TIP: In cases where team members do perhaps by trading work with someone else, or not feel safe in front of a manager, the perhaps he could take some time off. In this manager can help change this by example, it would also be helpful if the manager avoiding criticizing developers’ work in complimented Pierre on the work he has done so front of the group, or by not attending

far and expressed an interest in hearing how things future retrospectives. Remember,

turn out over the next few days. These practices retrospectives are not about criticism;

they are used to reflect on the work the conenvitrronibumteentto, Paiersare feis enmorvireonlmikelenyt . toIn besuchhoneanst team has done and to determine what

changes should be made.

about future impediments and to be a more

productive team member overall.

Functional and Dysfunctional Team Cultures

Retrospective meetings are also facilitated by team culture. Team cultures can either be functional or dysfunctional.

A functional team culture is similar to a safe environment, except it is an environment where people actively contribute instead of just feeling they can. In a functional culture, everyone tries to make everyone else look good, and the ownership of work is shared among the team. In this kind of culture, there are no secrets or guarded language, as success belongs to everyone, not just an individual. Meetings are constructive.

In functional team cultures, the productivity and decision-making of the retrospective meeting is driven by the team members and not by managers. This is because the team is motivated and takes ownership of the project.

A dysfunctional team culture, on the other hand, results when more pressure is placed on producing instead of improving. As a result, team members may become secretive and competitive in an unhealthy way in order to “look good” to management.

Decision-making becomes driven by self-interest instead of what’s best for the team. This can lead to a decrease in productivity.

Outside facilitators are sometimes brought in to help teams collaborate effectively. Outside facilitators are people who guide the retrospective process by creating a safe and trusting environment for discussions. They are also responsible for ensuring that all team members, including managers, contribute equally in meetings and do not avoid tough issues. Outside facilitators should be well acquainted with the goals of the retrospective.

It is good practice to do a retrospective at every major junction in a project, as they can help developers see a project objectively, so that

improvements can be made.

TIP: It is important to remember

that team members do not usually Good retrospectives are: start on projects to ruin them.

Instead, they usually want the

• organized and motivated by the development project to do well. Blaming

team problems on developers is likely

• driven by objective data, such as velocity or inaccurate, and it is more

defect analysis productive to reflect on why things

• done regularly by the development team might have gone badly. This helps
• a safe place for team members to mend feelings kimeeprovp oembservenatsti eaonss obier to jecitidvee antifnyd .

and build trusting relationships in the team

In-Depth Sprint Retrospective

This lesson outlines an example of a successful sprint retrospective. A sprint retrospective should be the last thing that occurs in a sprint. It usually happens after a sprint review meeting, which demos the product to the client or Product owner—it is a review of the product itself. As outlined before in this module, a sprint retrospective meeting is where the process is reviewed, so what is working in the product and what can be improved can be identified. This is keeping within Agile methodologies, which requires both product and process to be reviewed

and adapted.

To that end, sprint retrospective meetings should focus on issues about the process of the work, such as underestimated tasks in the last sprint, highlighting good work, or the implementation of an iteration burndown chart. Issues related to the product or features should not be discussed in a sprint retrospective meeting.

Sprint retrospectives should be time-boxed meetings set for an hour. However, these meetings do not need to be as strict as other Scrum events that are time boxed. If issues arise that should be discussed, the meeting may go over an hour.

Three major questions are addressed in a sprint retrospective meeting. These are:

1. What went well this sprint?
2. What did not go well this sprint?
3. What could be improved for the next sprint?

This is the best order to ask the questions. It allows the meeting to start on a positive note, and it gives the Scrum Master an opportunity to show their appreciation and recognition of the development and their work. Then, the second question allows criticism, but this should be facilitated by the Scrum Master so that team members do not feel attacked. The meeting should be honest but respectful. Finishing with the third question allows the team to feel constructive. The team should not finish with negative feelings, but instead should have something to look forward to, such as improvements for the next sprint. Using this order is especially important if the sprint did not go well. It prevents the team from starting the next sprint with negative feelings.

Sprint retrospectives are excellent opportunities to help the development avoid larger issues down the line.

Retrospective Exercises

Project retrospective meetings address the entire project instead of only a sprint. However, like sprint retrospectives, project retrospectives hope to discover what went well in a project, what did not go well, and how to improve future work. This means that what specific features do is not the focus of retrospectives. Instead, how features are implemented and the success of those features is addressed. For example, analyzing the fact that users can customize their avatar in a gaming app is not the purpose of a retrospective. But, how the team created this feature, such as how the team worked together to create the code can be examined. Because of this broader scope, project retrospectives tend to take quite a bit longer than an hour to discuss. Remember, some projects last months or even years, so there may be many issues to reflect upon and address.

This lesson is largely based on the book Project Retrospectives – A Handbook for Team Reviews (2001) by Norman L. Kerth (see the Course Resources). In his book, Kerth (2001) suggests project retrospective meetings should take three days. Although this seems like quite a long period of time, it is likely the three days will yield many ways time can be saved in future projects. The meeting should therefore save more than three days of time in the future. It is an investment.

Kerth (2001) compares the three-day project retrospective to a three-course meal, where each day corresponds to a course.

• The appetizer is the readying course. In this course, ground rules are set out for the retrospective. The purpose of the readying course is to build up trust among team members and to help the team realize what they have accomplished.
• The main course is the past course. During this course, the team reviews everything that occurred during the lifecycle of the product. It is also an opportunity to share all aspects of the project with the team, as some members may have been specialized and unaware of certain aspects. This may also help identify root causes of any issues.
• The dessert is the future course. This course allows the team to look forward to future

work and to suggest ideas for improvement.

Although three days is the suggested meeting length, it is important that courses are not extended just to fill the time. If all issues are addressed, then it is possible to move forward to the next course.

All of these events require preparation. This lesson shares a number of exercises a retrospective facilitator could use for each of the courses to help the meetings go as smoothly as possible. These exercises are generally implemented in the appropriate meetings. However, not all exercises need to be executed in every project retrospective.

Teams should be able to assess which exercises would be most beneficial to their projects. In all cases, safe environments should be maintained.

If you are interested in more information on the retrospective exercises outlined here, you can read more about them in Kerth’s book.

Preparation Exercises

Before any of the retrospective courses happen, sometimes a retrospective pre-work handout is used. A retrospective pre-work handout is a handout that is emailed to everyone invited to participate in the retrospect. It contains a list of questions that can help identify general patterns that might arise during the meeting.

Once participants have a copy of the questions, they are encouraged to write down answers before attending meetings. If people write things down, they are more likely to share them. A retrospective pre-work handout also encourages participants to think about issues before the meetings begin.

Kerth suggests the following questions:

• What topics should be discussed in the retrospective, in order to make sure we learned the most from this experience?
• What do you hope will happen during the retrospective?
• What long-term impact do you hope this retrospective will have?
• What reservations, concerns, or worries do you have about this retrospective?
• What emotions do you feel as you think about this meeting?
• What else should I ask, and how would you respond?

Once team members have responded, their answers go to the facilitator, usually by email. Responses should remain private and are only used to help the facilitator identify general trends that may need to be discussed.

Outside facilitators may want to introduce themselves to the team beforehand. This helps establish a basis of trust and gives facilitators an opportunity to discuss the project in person with people. This can help them further identify trends with the pre-work handout. Facilitators can also use this opportunity to remind people to complete the pre-work handout and to bring artifacts to meetings (artifacts will be discussed later in this lesson).

Readying Course Exercises

Readying course exercises focus on establishing trust and designing ground rules that create safe environments. They should also convince the team that the retrospective meeting will result in positive outcomes.

Past Course Exercises

There are a number of past course exercises used as well.

Future Course Exercises

A couple of future course exercises are outlined in the following table.

Check List

• Explain different process models for structuring software development.
• Determine which process model works best for different software development projects.
• Apply the fundamentals of Agile software development practices, such as Extreme Programming (XP) and Scrum.

Introduction to Processes

• Summarize the concept of a process.
• Define the process terms: life cycle, phase, activity, task, work product, resource, and role.
• Understand the hierarchical relationships of: processes, phases, activities, and tasks.
• Differentiate between how tasks consume, use, and produce resources and work products.
• Determine how practices align with a process.
• Define and identify a practice and a methodology.
• Summarize key software engineering activities.
• Recognize the inputs and outputs of each activity.
• Summarize the phases of an example software engineering process.
• Identify the software engineering activities in each phase.
• Define project management tasks and activities that are ongoing throughout all phases: risk management, performing estimation, and allocating resources.
• Understand the differences between expressing, gathering, and eliciting requirements.

Process Model

• Explain the need to consider various process models.

• Fully describe a linear model including its strengths and weaknesses, and its phases in the correct order. This includes:

  • Understanding the similarities and differences of the linear models: Waterfall, V-Model, and Sawtooth.

• Fully describe an iterative model including its strengths and weaknesses. This includes:

  • Understanding how phases relate to iteration in the iterative Spiral model.

• Fully describe a parallel model including its strengths and weaknesses. This includes:

  • Describing the specific phases associated with Unified Process models.
  • Understanding how Unified Process models can accommodate parallel activities, but that phases cannot happen in parallel.

• List and describe the five types of prototypes: illustrative, exploratory, throwaway, incremental, and evolutionary.

• Differentiate between prototypes, including:

  • Evolutionary and incremental,
  • Illustrative and exploratory, and
  • Illustrative and throwaway.

Reference

Software Product Management Specialization

The 12 Principles behind the Agile Manifesto