# Software Process

Let's discuss the process of developing software.

People like to think that building software is like building anything else, e.g., a car. At first glance is seems reasonable: you determine some requirements for what you want to build, design it, and then build a prototype. You refine your production process, and eventually you can mass-produce many of those objects. Profit!

Except it's not quite like that. Software has characteristics that make it very different from traditional manufacturing:

• It's intangible and abstract. There is no physical product being produced.
• Software is highly customizable. You can design software to do practically anything (that is possible within it's limited domain).
• Software may be expensive to develop, but it's relatively cheap to distribute since distribution can often be done digitally i.e. with no physical copies required.
• Once "built", we can make as many copies as we wish at little to no additional cost. You can't do this with a tangible product! (The next-closest thing might be a book or music or some expression).
• Software doesn't "wear out" like a physical product but it requires ongoing maintenance as new features are introduced, or the operating environment changes e.g. new OS versions being released, driver updates.

Software is also highly dependent on the environment in which it operates. Yes you can "do anything" in a software system, provided that the underlying hardware/operating system/toolchain supports it.

A software process is a collection of activities, actions, and tasks that we perform when creating software. An activity is used to achieve a broad objective (e.g., communication with stakeholders) and is applied during the process. Actions (e.g., architectural design) encompass a specific set of tasks that may be used for a particular activity (e.g., an architectural model).

# Project Activities

We can identify activities that are applicable to all projects, regardless of their size or complexity. A generic process framework for software engineering encompasses five activities:

• Communication: We need to define the problem that we're trying to solve, and discuss the goals and requirements with the customer, potential users, and other stakeholders. This is critical to ensure that we're building the "right" product or solving the main problem that needs to be addressed.

• Planning: This involves defining the tasks that need to be completed, and high-level milestones that you need to reach. It also identifies people and resources, potential risks to the project, and ways of mitigating these risks. These are what we would typically call "project management" activities.

• Modeling: It's always cheaper to think ahead prior to actually building something. This step includes design efforts to create abstract models or representations of the product that you need to build. By iterating on a design, you refine your understanding of the problem, and move towards a more-correct solution. This is crucial before you actually start building it, both to improve the accuracy and usefulness of what you build, but to minimize costs.

• Construction: The process of building your product i.e. realizing your design. This may require successive iterations to complete all the required features, and should also include some level of testing and validation.

• Deployment: Tasks required to produce a working product and deliver it to the customer. This includes collecting their ongoing feedback and making revisions as needed.

The people impacted by your product are called stakeholders. This includes the people who will use your solution, but can also include anyone else that is affected by it. For example, in a software project, stakeholders can include users, the IT department who will install and maintain your software, people who rely on the output of your program and so on.

# Process Models

We use the term process model to describe the structure that is given to these project activities.

A software process model is simply a type of process model adapted to describe for software systems. It defines the complete set of activities that are required to specify, design, develop, test and deploy a system, and describes how they fit together.

Software activities tend to be named slightly differently than the activity names that we've been using:

Compared to the standard model, we've split Planning into separate Planning and Requirements definition. These activities are often performed by different departments or individuals, so traditionally they're split apart. Analysis & Design corresponds to Modelling, and Implementation and Testing together correspond to Construction.

This is a simplified understanding of a software development project. People generally accept that we have planning, formal requirements, modelling and design, implementation and testing—but there are lots of disagreements on how these pieces "fit together." Let's continue talking about the structure of software projects.

# Waterfall model

In the 1970s, there was a concerted effort to formalize 'known-good' methods of project management. Software projects were seen as expensive and time-consuming, and there was considerable pressure to improve how they were managed. In a 1970 paper, Winston Royce laid out a mechanism for formalizing the large-scale management of software projects [Royce 1970], dubbed the Waterfall model. This envisions software production as a series of steps, each cascading into the next one, much like a waterfall. In this model, requirements are defined first, a design is created and then implemented, then tested and so on. Software development is treated as a set of linear steps that are followed strictly in-order.

The Waterfall Model, as understood and practiced for a long time, most closely resembles a linear project model, and is similar to how other construction or manufacturing projects are organized.

The Waterfall model the following characteristics:

• A project starts at the top and advances through stages. Each stage must be completed before the next stage begins.
• The stages are modelled after organizational units that are responsible for that particular stage (e.g. Product Management owns Requirements, Architects own Analysis & Design, QA owns Testing and so on).
• There are criteria that need to be met before the project can exit one stage and enter the subsequent stage. This can be informal (e.g. an email letting everyone know that the design is "finished"), to a more formal handoff that includes artifacts (e.g. Product Requirements documents, Design documents, Test Plans and so on).

This linear approach strongly suggests that you can and should define a project up-front (i.e. determine cost, time and so on).

What's wrong with this model?

If you're a project manager, or a business owner, the Waterfall model is very appealing: it suggests that you can define work up-front, and plan out time, costs and other factors. This models suggests that you can work out the parameters of a project, plan and execute it.

However, this isn't realistic.

1. Requirements can and will change as project development is underway. This is partly because the context in which the product is being developed will also change, often in ways that we cannot anticipate (e.g., the market changes, so new features become important; the customer needs to pivot on early decisions). Our understanding of the problem that we're solving will also change as we're building something, which can result in unexpected requirements changes as well.
2. Implementation and related activities are not that predicable! We are often building new features or combinations of features; building something novel is always going to be challenging and have some levels of uncertainty (in how long it will take, and what the solution will look like).

How do we fix this? We need to consider alternative process models. Enter Agile.

# Agile Development

By the mid-90s, there was a widespread recognition that the 'old ways' of building software just didn't work -- either for developers or for customers.

• Developers were frustrated by rigid processes and changing requirements.
• Business owners were frustrated by the inability to make changes to projects in-flight.
• Projects were often late and/or over-budget. This frustrated everyone!

There were a number of new, competing, process models introduced during this time. No one single model dominated. Instead, this movement culminated in 2001, when a group of software developers, writers, and consultants signed and published the Manifesto for Agile Software Development.

Agile was an attempt to find some common-ground principles across competing process models. It isn't a process model by itself, but a set of principles that influenced the development of other models.

What does this mean?

1. Individuals and interactions (over processes and tools): Emphasis on communication with the user and other stakeholders.
2. Working software (over comprehensive documentation): Deliver small working iterations of functionality, get feedback and revise based on feedback. You will NOT get it right the first time.
3. Customer collaboration (over contract negotiation): Software is a collaboration between you and your stakeholders. Plan on meeting and reviewing progress frequently. This allows you to be responsive and correct your course early.
4. Responding to change (over following a plan): Software systems live past the point where you think you’re finished. Customer requirements will change as the business changes.

"Agile Software Development" isn't a single process, but rather an approach to software development that encompasses this philosophy. It encourages team structures and attitudes that make communication easier (among team members, business people, and between software engineers and their managers). It emphasizes rapid delivery of operational software, but also recognizes that planning has its limits and that a project plan must be flexible.

There are a large number of software process models that were developed at this time, including Extreme Programming (XP) [Beck 1999], Scrum [Schwaber & Sutherland 1995], Lean [ Poppendieck & Poppendieck 2003]. Collectively, these are called "Agile Processes."

Much of this section is based on a more thorough discussion of Agility by [Pressman & Maxim 2020].

Agile is also implicitly about shifting power and decision-making from product managers and other business leaders to the development team, the ones actually building software. At least part of the failure of previous models is the failure to understand that development is not usually predictable. We're often building something for the first time, or solving a unique problem, so it's extremely difficult to predict the outcome far in advance.

# Assumptions

Any agile software process is characterized in a manner that addresses a number of key assumptions about the majority of software projects:

1. It is challenging to predict in advance which software requirements will persist and which will change. It is equally challenging to predict how customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interwoven. That is, both activities should be performed in tandem so that design models are proven as they are created. It is challenging to predict how much design is necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.

Given these three assumptions, how do we create a process that can manage unpredictability?

Central to Agile processes is that any process must be adaptable to rapidly changing projects and technical conditions. It must also be incremental and incorporate customer feedback so that the appropriate adaptations can be made.

This idea of an iterative, evolutionary development model remains central to all Agile processes (although they may present it differently). Instead of building a "complete" system and then asking for feedback, we instead attempt to deliver features in small increments, in a way that we can solicit feedback continuously though the process. Over time, we will add more features, until we reach a point where we have delivered sufficient functionality and value for the customer.

# Benefits

Agility means recognizing that requirements and plans will change over time.

1. Software is too complex to design and build all at once. It’s more manageable to add features and test incrementally.
2. Software is in a constant state of change, and requirements will change during the development cycle[.

The conventional wisdom in software development is that the cost of change increases as a project progresses. Agility is often characterized as "embracing change" since it expects project and requirements changes, and is constantly reassessing the state of the project. The benefit of Agile is that it reduces (and tries to eliminate) breaking late-project changes.

There’s a common misperception that software can be “finished,” shipped and then ignored. That’s not really true. By the time software reaches the market, the conditions will have changed (e.g. a competitor has introduced a feature, or you need to support a new type of device). Software needs to be constantly updated to keep up with changing environments (e.g., OS versions). Simple programs may last years without requiring updates, but as a program becomes more complex, it's more likely to need ongoing maintenance.

Now we just need to pick from the many Agile models that exist.

# Agile Models

We have many iterative process models that we can consider. We'll look at two important models: User-Centred Design, and Scrum.

User-Centred Design focuses on understanding user needs, and is useful for defining meaningful project requirements. Scrum is helpful in scheduling and managing those requirements, and tracking their progress over time.

# UCD

In the mid 1980s, while on sabbatical at the Applied Psychology Unit at Cambridge University, Don Norman found himself puzzled by the light switches he encountered. Why light switches? As the story goes, the switches moved in the opposite direction to what he expected ("up" denoting "on" by North American convention, while at Cambridge they worked in the opposite direction ). This led him to consider the "perceived affordance" between user and item being used; the visual "hints" that suggest how something should be used. In other words, “how we [manage] in a world of tens of thousands of objects.”

These ponderings eventually led to the publication of his book, The Design of Everyday Things in 1988 [Norman 1988, 2013]. In this book, Norman presents case studies of objects we interact with everyday, from door handles to computers and phones. He shows what good and bad design look like across a wide spectrum of devices, inviting us to think about all the daily "user experiences" we take for granted. He wasn't thinking about software explicitly, but his insights apply equally well to that domain.

For Norman, the two most important characteristics of good design are discoverability -- the ability of a user to determine the purpose of an object -- and understanding -- figuring out how it works and how to use it. From Norman's perspective, good design should make these characteristics obvious and intuitive.

Norman illustrates what he considers the fundamental principles of interaction:

• Affordances: cues that allow a person to figure out what an object does without any instructions. e.g. a door with a "pull" handle (formally called "perceived affordance", which positions then as properties of the perceiver, as much as the object itself).
• Signifiers: visible signs or sounds that communicate meaning. They indicate what is happening, or what can be done. e.g. a door that says "push" on it.
• Mapping: the relationship between two sets of things that conveys associated meaning. e.g. grouping controls and putting them next to the thing that you want to manipulate.
• Feedback: the result of an action, communicated to a user. e.g. a button changing color when depressed; a walk indicator that lights up when the walk button is activated.
• Conceptual models: simplifed explanations of how something works; related to mental models that people automatically form when working with an object to help them explain and predict its behaviour.

"Good design" is about reducing the friction between the user's intention and the outcome of interacting with an object. In order for something to be useful, it needs to serve a clear purpose for some user, and it also should be intuitive to use (in other words, designed using these principles).

So how do we know when we have things "right"? We talk to users! We iterate on our designs, collect feedback and made revisions until we get the best design that we can. Norman's insights kick-started a shift towards design-first, and directly led to the emergence of UCD and modern UX.

User-Centered Design (UCD) is a design process that focuses on addressing the needs of users first, to ensure that we're building a high-quality solution and solving the correct problem for our users. UCD uses a mixture of investigative tools (e.g. interviewing) and generative methods (e.g. brainstorming) to design systems based on user needs, and collect feedback through the process.

What are the underlying principles of UCD?

1. Understand and address the core problems. Ensuring that we solve the core, root issues, not just the problem as presented.
2. Be people-centred. We are designing software for people. A well-engineered solution that nobody uses is a failure.
3. Use an Activity-Centred Approach. Design must focus upon the entire activity under consideration, not just isolated components. Most complications result from the interdependencies of multiple parts.
4. Use Rapid Iterations of Prototyping and Testing. Continually test and refine our solution, and get feedback to ensure that it truly meets the needs of users.

How do we apply these principles? We use a user-centred process like this:

1. Consider your users — perform user testing, and create personas and user scenarios in order to learn more about the ways your users interact with their current mobile products. This will help you gain a higher-level picture of your target users.
2. Prioritize content — your user research will give you a deeper understanding of user expectations. Put this to good use, and focus your attention on designing features and behaviour that users want the most, as well as what your business expects.
3. Review and refine — create wireframes and prototypes of your mobile designs to help your team visualize each screen and its content. Add interaction to make them more lifelike as you move up the prototyping fidelity spectrum.

UCD is frequently mistaken for UX (User Experience). They are related but not identical. User-Centred Design is the process of considering users through planning design and development of a product. It’s a set of steps and methods that we can use to ensure that we are designing for users. User Experience (UX) is the conceptualization of a user’s full experience with a product. It’s concerned with the user's perceptions of the entire solution.

# Understanding Users

The first step to building a solution for someone is to understand who they are, what challenges and constraints they face. You want to be able to clearly state:

• "Who are my users?"
• "What are they trying to accomplish?"
• "How do they relate to the problem that I'm trying to solve?"

This is a key objective that must be addressed up-front. In some situations, you may be told what users to target, and your early efforts might be focused on interviewing those people and to refine your understanding (e.g. imagine you're told to create a new system for airline booking agents; you would probably start by interviewing everyone that relates to that role, who in turn may help you identify other potential users). In other situations, your users may not be obvious: you may need to interview people to determine your potential user base.

Interviews

The best way to understand a set of users is to talk to them! You may need to interview people just to figure out how they relate to your product idea. Start by interviewing potential users, and then look at your results—you can always narrow down to a subset of users later.

Interview guidelines

• Interview 5–6 users [Nielsen 2000]
• Ask open-ended questions to understand what they do, how they work.
• Continue asking questions to identify issues or challenges that they might have.
• Use followup questions to make sure that you understand their goals and motivations.

The outcome from interviews should be detailed interview notes.

Good interview questions:

• Describe a problem that you have.
• How would you accomplish X?
• What do you like about this system? What do you dislike?
• How would you expect (some feature) to work?"

Another useful technique for gathering information is to survey users. Surveys are relatively inexpensive, and it is fairly easy to collect information from a large group of users quickly. However, response rates for surveys tend to be low, and you are limited to fairly simple questions (plus, unlike interviews, you cannot ask follow-up questions!).

From your interview notes, it can be helpful to characterize your target users and the tasks that they want to perform. This involves the generation of Personas and User Stories.

Building Personas

A persona is an archetypal description of a user of your application or product. They are often based on "real people" but are generalized descriptions that represent a category of people that share similar characteristics. We use personas a stand-ins when discussing product goals and features.

Each role or "type" of user that you identified should generate a unique persona. You typically have two or three personas for even a small solution.

To build a persona, you interview one or more users representing that role in an organization. You then write a fictional portrait of a user, which represents the consensus among your users in that role as accurately as possible.

There are some basic elements that your user persona should include:

• Personal info: Present personal information first, including name, job title, company, job description, family status, and more. Include any details that can help your team understand the persona better.
• Demographic info: Other demographic information, such as age, gender, income, education, location, and other background information can help you create a more authentic character.
• Image: Images speak louder than words. A vivid image, sketch, or cartoon can help your team picture your users clearly, and help you establish a consistent understanding of the target users. Use a photo that reminds you of this user.
• Goals: You should also make it clear what your audience wants to get or to do with your product. List all possible goals and motivations that you've found from your user research.

Here's some examples:

You can find our templates in the GitLab public repository repository, but we generally recommend Figma for creating diagrams! It has templates for all diagram types, including Affinity Diagrams, Personas and even UML diagrams.

# Analyzing Interview Data

User Stories

From your user interviews, you should have identified some basic tasks that you will need to address. Often, these will come in the form of stories or narratives from your users, which you've recorded. Your job in this step is to extract these common stories or tasks from your interview notes.

User-Stories are a description of activities that are performed with a system to perform a particular task. A user story is often simple text, and is intentionally describing the problem at a high level:

"As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager."

"As a user, I can indicate folders not to back up so that my backup drive isn't filled up with things I don't need."

User stories are useful because they help identify users and their high-level goals, and they serve as an excellent starting point for discussions.

User Story Maps

Once you've collected a number of user stories, you might arrange them into User-Story Maps to show their larger relationships. They can also be plain-text, but often include diagrams, sketches and other visual elements that help describe a user's interaction with the system.

Story maps are intended to spark collaboration and conversation among Agile team members, while providing them with the bigger picture of how the digital product flows and fits together. -- Nielsen Norman Group

User Stories Maps often include three levels:

1. Activities represent the high-level tasks that users aim to complete in the digital product. e.g. deposit a cheque.
2. Steps sit directly underneath activities and also display in sequential order. They represent the specific subtasks that users will go through in the product to complete the activity above. e.g. enter pin, select deposit from the menu, and so on.
3. Details are the third level of the story map and describe the lowest-granularity interactions that the team anticipates users will experience to complete the step above. e.g. enter pin by pressing the numbers in order, and ok when complete.

The user stories that you have captured can also be thought of as features of your software. You can (and should) record these in as much detail as you have; it's a good time to create issues in GitLab to document them.

You probably don't want to rush to implement these requirements until you have iterated over them and expanded them a little more. We want to consider a number of different perspectives: technical (can we build this), architectural (what is the impact on the system if we build this) and UX (how well will this work for the user)? Let's consider user feedback first.

Affinity Diagrams

The outcome of your interviews will likely be a lot of qualitative data—opinions, suggestions and ideas that the user expressed. The challenge is extracting ideas, themes from this narrative that you can use in your design.

We use thematic analysis to do this, and the mechanism that we will use is the creation of an affinity diagram.

To create an affinity diagram:

1. Record all notes or observations on individual cards or sticky notes
2. Look for patterns in notes or observations that are related and group them
3. Create a group for each pattern or theme
4. Give each theme or group a name
5. Create a statement of what you learned about each group (provide your analysis or key insight)

You should end up with clusters of related ideas, all around a common theme. You can them examine these to expose critical ideas or themes from the user's ideas. (You can even do this across multiple users and look for themes which occur more frequently!).

Figma has templates for all diagram types, including Personas, Affinity Diagrams, and even UML diagrams.

# Prototyping

From our user stories, we can start to think about user interaction and the user interface. E.g., In our hypothetical note-taking application, we might have identified a user story around multi-user support. That suggests that we need a way to create accounts, store credentials safely, login using those credentials. Once logged in, users probably need a way to change accounts. These are all activities (from our user story map) that require individual screens and an understanding of how the user navigates through these screens to accomplish an activity.

Designing this complex interaction can be challenging. You will want a way to design the user interaction, review it with your team, and get user feedback before implementing it. You don't want to build, discard and rebuild your application as part of your process—that's too costly and time intensive. Instead, we build a prototype-a low-effort implementation that we can use to solicit feedback.

Think of a prototype as a mockup of part of a system. It is NOT an "early version" of release software, but an early demonstration of functionality intended to elicit feedback from users.

Compared to the full implementation, a prototype requires significantly less time to build. This makes it much easier to discard or modify as you work through design iterations. Prototyping lets us get to a final version much faster!

We often characterize prototypes based on their complexity:

• A low-fidelity prototype is deliberately simple, low-tech, and represents a minimal investment of time and effort. They are shown to users to elicit early feedback on layout, navigation, and other high-level features. Low-fidelity prototypes can be sketches on paper, or non-interactive wireframe diagrams.
• A high-fidelity prototype represents a more significant effort and is intended to be close to the final product. They are suitable for demonstrating complex functionality with a high degree of interaction. Commercial products exist for this purpose, e.g., Figma, Miro or Sketch that allow you to "mock up" a user-interface in much less time that it would take to build the final product. These tools provide collaboration features, so that a designer can build up prototypes quickly, demo them to elicit feedback and even make changes on-the-fly.

This diagram shows the progression from low to high fidelity. It's not required to build at different dimensions like this! You want to build at the lowest level that you can for maximum benefit.

User interfaces are interactive! To capture this, our prototypes should include:

• Mockups of all your screens, at a level of detail that shows important information and suggests interaction.
• The relationship between these screens. How do you navigate between them? How are they related?
• Enough clues (affordances) to suggest how functionality is activated. The user should be able to tell how to perform major tasks.

# Intro to Figma

Figma is a collaborative design tool that allows designers to build a range of interactive prototypes. We'll use it to build UI prototypes, and then we can show these to potential users and stakeholders (including our team members) for feedback before we implement features.

Figma is primarily an interactive website (although it also has client applications you can install). Figma has free and paid plans. As a student, you can sign up for a Figma for Education plan for free, which provides paid functionality. Highly recommended while you are still in school!

A design in Figma is meant to encompass all interactions for a product. It consists of:

• a frame, representing a single UI window (e.g. Android Pixel C screen, or 14" MacBook Pro Desktop).
• UI elements, represented by customizable shapes.

Figma presents itself like a vector drawing application, letting you "build" a user interface much like you would in any drawing application. However, unlike drawing applications, it also supports adding interaction e.g. clicking buttons.

You can build your UI screen by

1. Adding a frame,
2. Adding primitive shapes (rectangles, circles) to represent UI elements. Use the property sheet on the right-hand side to align, change properties, and so on.

This is slow; you can also import and use Component Libraries that the Figma community has made available. In a browser, navigate to the Figma Community page. From this page, you can search and import libraries directly into your Figma account.

A library is just a set of predefined components. Using a library instead of designing your own has some advantages:

• You can save a lot of time!
• The components in a library will have a similar look-and-feel.
• You can use libraries to mimic the appearance of standard platforms e.g., iOS.

For example, here's a sheet from the Mobile Wireframe library, which includes iOS, Android components.

You can create a new diagram, and copy-paste these components into your screens. Minimally, your initial prototypes should include labelled wireframe diagrams for every screen (displaying the structure of your application and each of the screens).

To do anything more complicated, it's recommended that you review the Figma Documentation or watch some introductory videos.

# Iterating on designs

You should plan on taking your design back to your team, and to your users for feedback.

• Start with low-fidelity prototypes to capture high-level feedback (e.g. "Does this screen make sense to the user? Do they know what they should do?")
• Once you have addressed high-level feedback, consider adding interactive elements e.g. buttons that navigate through the screens so that you can capture feedback on the interaction, and the larger workflows.
• Save high-fidelity prototypes for complex features or complex interactions.

# Scrum

Scrum is the standard accepted process model for managing scope during a project iterations, i.e., it's focused on the overall project structure. Scrum breaks down a project into fixed-length iterations called sprints (typically 2-4 weeks in length for each sprint). Sprints are defined so that you iterate on prioritized features in that time, and produce a fully tested and shippable product at the end of each sprint.

Typically, a project will consist of many sprints, and you will iterate until you and the customer decide that you're done (i.e., the only remaining requirements are deemed low enough priority that you decide to defer them or not complete them). Practically, having a buildable and potential "shippable" product at the end of each cycle is incredibly valuable for testing, demonstrating functionality to customers, and it provides flexibility in how you deploy.

In Scrum, everything is structured around sprints:

Key Concepts

• Product Owner: the person responsible for gathering requirements and making them available in the product backlog. They are not considered part of the project team, but represent both the external business and customer. At the start of each sprint, they work with the team to prioritize features and decide what will be assigned to a sprint.
• Product Backlog: a list of all possible features and changes that the Product Owner thinks should be considered. There is no guarantee that these will all be developed! The team must agree to bring features forward into a sprint before they are developed.
• Sprint Backlog is the set of features that are assigned to a specific sprint. This is the "scope" for that sprint.
• The Scrum Master is the person that helps facilitate work during the sprint. They are not in charge (!) but track progress and help identify blocking issues that might prevent the team from meeting their deliverables.
• The Daily Scrum is a standup meeting where you discuss (a) what you've done since the last meeting, (b) what you intend to do today, and (c) any obstacles that might prevent you from accomplishing b. The Scrum Master runs this meeting, and the entire team attends.

Sprint Breakdown

The following steps are followed in each sprint:

1. The project team and Product Owner collectively decide what requirements to address, and they are moved from the Product Backlog to the Sprint backlog. Once features have been decided, you do not allow any further scope changes (i.e. you cannot add anything to the sprint once its started). Work is actually assigned to team members (and you collectively agree that you believe it can be completed in the sprint).
2. During the sprint, you iterate on the features in the Sprint Backlog. This includes design, development, testing until you complete the feature or the sprint ends. The Scrum Master facilitates daily meetings to make sure that nobody is "stuck" on their feature.
3. At the end of the sprint, have a review with the team to see what was accomplished. Demo for the Product Owner (and sometimes the actual customer). Reflect on your progress, and be critical of how you might improve process the next sprint. (e.g. could we have communicated better? should we have done more testing during the sprint? did we take on too many features?)

What do we like about Scrum?

• It provides structure for your iterations.
• It acknowledges that we can and should iterate over most of our activities. In other words, we always start a sprint with requirements (deciding what to include), design (elaborating on a feature), implementation, and testing.
• It explicitly identifies how to handle user feedback. We ask for input at the start of the sprint, and demo for feedback at the end of the sprint.

# XP

Extreme Programming (XP) is an Agile methodology focused on best-practices for programmers. It was based on a large-scale project that Kent Beck managed at Chrysler in the late 90s, and attempted to capture what was working for them at that time. It aims to produce higher-quality software and a higher quality-of-life for the development team. XP aims to help us build high-performing software teams.

Core Values The five core values of XP are: communication, simplicity, feedback, courage, and respect.

• Communication: The key to a successful project. It includes both communication within the team, and with the customer. XP emphasizes face to face discussion with a white board (figuratively).
• Simplicity. Build the "simplest thing that will work". Follow YAGNI ("You Ain’t Gonna Need It") and DRY (Don’t Repeat Yourself).
• Feedback. Team members solicit and react to feedback right away to improve their practices and their product.
• Courage: The courage to insist on doing the "right thing." The course to be honest with yourselves if something isn't working, and fix it.
• Respect: Respect your team members; accept that development is a collaborative exercise.

Best Practices XP launched with 12 best practices of software development [Beck 2004]. Some of these (e.g. The Planning Game, 40-Hour Week, Coding Standard) have fallen out of disuse. Others have been added or changed over time, so it is difficult to find a "definitive" list of commonly used XP practices.

This is ok, and actually aligns with the practice of fix XP when it breaks.

Although some XP practices never really worked very well, many have been adopted as "best practices." We'll revisit these in the next section.

XP is rarely used as-is. It’s common for development teams to adopt one or more of these ideas based on what suits them, and their environment. For example, daily stand-ups are very common, but very few places will implement pair programming.

# SDLC

Let's revisit our lifecycle diagram.

There is no single set of practices that will work in every environment. It's common (and reasonable!) for organizations to adapt practies to suit the pecularities of their environment.

In this section, we'll piece together UCD and Agile practices into a working SDLC that suits this course and our objectives. We will "borrow" practices that make sense in this context, and ignore others that simply won't be as useful in our particular situation.

# Diagram

Let's add UCD and Scrum practices to our previous SDLC:

Here's how to read the diagram:

• Each project starts with some basic planning activities. These are typically identifying team members and other resources, critical milestone dates and other variables for your project. (In this course, you are given all of these factors up-front! Your main planning activity is finding team-mates).
• Use the UCD to identify users, a problem to address and potential features. You should also prototype your user interface and get feedback from users.
• Implementation includes multiple iterations, where you choose features; design, code and write unit tests, and evaluate your results with users.

Each development iteration is a fixed-block of time, called a sprint (taken from Scrum). In a typical development project, sprints should be relatively short, from two to four weeks in length, and the team typically works through multiple sprints until the project is completed.

In our course, Sprints are two-weeks long, and we will have four sprints in total (i.e. 4 x 2-week sprints).

# Activities

Each sprint includes the following activities:

1. Feature Selection: On the first day of the Sprint, the team meets and decides what features to add (and what bugs to fix) during that iteration.
2. Implementation. During most of the sprint, the team iterates on their features. As each feature is completed, it is tested.
3. Evaluation. At the end of the Sprint, the team meets with the Product Owner to demonstrate what they have completed, and get feedback. The team also has a Retrospective, where they reflect on how to improve.

The cycle repeats for however many Sprints the team has available (or until they decide they are "done"). The product should be usable and potentially shippable to a customer at the end of each Sprint. The team may not always complete everything that they planned for a sprint, but the features that are implemented need to be bug-free.

Each sprint is supposed to result in a product release of high enough quality that it could be deployed.

This process model incorporates the XP ideas of iterations, iteration planning and small releases.

# Last Word