1.2 Aspects of Agile Approaches
Let us have a look at some of the Agile approaches like:
- Collaborative User Story creation
- Retrospective
- Continuous Integration
- Iteration and release planning
1.2.1 Aspects of Agile approaches
Figure: Agile Methodology. START: Initiate Project, Define Requirements, High Level Requirements > Development 1, Add functionality 1. Integrate and Test > Development 2-3-4-n, Add Functionality 2-3-4-n. Release. Feedback Review means Continuous Visibility for Clients, Developers and Users. Accept? Test Yes – Release to Market. Test No – Record and Incorporate Changes, Adjust and Track, Reprioritise Feature, Next Iteration inserted into Development.
- Agile methods are not unified; there is diversity
- Each method implements the Agile Manifesto differently
- In this course, we consider Extreme Programming, Scrum, and Kanban as popular, representative methods
- There are common practices across these methods, which we’ll examine.
Extreme programming (XP)
Extreme Programming (XP) is a software development methodology, which is intended to improve software quality and responsiveness to changing customer requirements. As a type of Agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Figure: Extreme Programming Practices. RED: Whole Team, Planning Game, Small Releases, Customer Tests. GREEN: Coding Standard, Sustainable Pace, Metaphor, Continuous Integration, Collective Ownership. BLUE: Test-Driven Development, Refactoring, Simple Design, Pair Programming.
Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed. It also includes a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.
The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, Code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of Pair programming.
Some key points;
- Values: communication, simplicity, feedback, courage, respect
- Principles: humanity, economics, mutual benefit, self-similarity, improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, accepted responsibility
- Primary practices: sit together, whole team, informative workspace, energized work, pair programming, stories, weekly cycle, quarterly cycle, slack, ten-minute build, Continuous Integration, test first programming, incremental design.
- Many other Agile practices use some aspects of XP.
Scrum
Scrum is a lightweight Agile project management framework mainly used for software development. It describes an iterative and incremental approach for project work.
Figure: The Scrum Management Framework. Key: Product Backlog, Product Owner > Sprint Backlog, Scrum Master > Sprint, Scrum Team, Daily Scrum > Sprint Review, Shippable Product Increment > Sprint Retrospective, Continuous Improvement and Customization.
Overview of Scrum Framework
Scrum can be used in all kinds of software development: for developing complete software packages, for developing only some parts of bigger systems, for customer or internal projects.
The Scrum Framework itself is very simple. It defines only some general guidelines with only a few rules, roles, artefacts and events. Nevertheless, each of these components is important, serves a specific purpose and is essential for a successful usage of the framework.
The Main Components of Scrum Framework are:
- The three roles: Scrum Master, Scrum Product Owner and the Scrum Team
- A prioritized Backlog containing the end user requirements
- Sprints
- Scrum Events: Sprint Planning Meeting (WHAT Meeting, HOW Meeting), Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective Meeting
Important in all Scrum projects are self-organization and communication within the team. There is no longer a project manager in a classical sense. In the Scrum Framework, the Scrum Master and the Scrum Product Owner share his or her responsibilities. However, in the end the team decides what and how much they can do in a given project iteration (Sprint).
Another central aspect within the Scrum Framework is continuous improvement: inspect and adapt. The Scrum Teams have to frequently inspect and assess their created artefacts and processes in order to adapt and optimize them. In the midterm, this will optimize the results, increases predictability and therefore minimizes overall project risk.
The Scrum Framework tries to deal with the fact that the requirements are likely to change quickly or are not completely known at the start of the project. The low-level requirements are only defined at the time when they are going to be really implemented. In Scrum, changes and optimizations of product, requirements and processes are an integral part of the complete engineering cycle.
Another cornerstone of the Scrum Framework is communication. The Scrum Product Owner works closely with the Scrum Team to identify and prioritize functionality. This functionality is written down in User Stories and stored in a Scrum Product Backlog. The Product Backlog consists of everything that needs to be done in order to successfully deliver a working software system.
The Scrum Team is empowered to only select the User Stories they are sure they can finish within the 2-4 weeks of Sprints. As the Scrum Team is allowed to commit to their own goals, they will be more motivated and work with best possible performance. The Scrum Master is another important role in the Scrum Framework as he or she works as a servant-master with the Scrum Team. His/ her main tasks are to make the Scrum team understand how Scrum operates, to protect the Scrum Team from external interruptions and to remove impediments that hinder the Scrum Team in reaching its maximum productivity.
The Scrum Framework in its simple form is best used for smaller, one-team projects. However, with the introduction of additional roles like the "Chief Scrum Product Owner" it is also usable in bigger multi-teams and/or distributed-team projects.
Kanban
Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and team members pull work from a queue.
- Optimize flow of work in value-added chain
- Instruments:
- Kanban board
- Work-in-progress limit
- Lead time
- Both Kanban and Scrum provide status transparency and backlogs, but:
- Iteration is optional in Kanban
- Items can be delivered one at a time or in a release
- Time boxing is optional
Figure: Kanban Knowledge Management. Key: Backlog Queue (Some Stuff), User Story X, Update User Profile; Current Top Priority Queue – TO DO (List Users, Defect XX...); In Progress (PoC Fail Fast Authorization); To Be Verified (Defect XY Under Age Allowed); Done; In Production (Login Page). Features: Continuously Prioritized Queue; Continuous Deployment; Development and Maintenance Combined!, Visibility and Joy! Created by Ole Morten Amundsen using Mockito. Us as you please.
1.2.2 Collaborative User Story Creation
Example of User Story: As a <customer> I want to <see the catalog of salable items> so that <I can order one of them>. As an <administrator> I want <to be able to disable accounts>. As a <trainee> I must <answer all the questions>
Some facts:
- Developers, testers, and business stakeholders collaborate to capture requirements in User Stories
- User Stories include:
- Functional and non-functional elements
- Acceptance criteria for each element
- Testers bring a unique perspective to this process
- Identify missing elements
- Ask open-ended questions
- Suggest tests for the User Story
- Confirm the acceptance criteria
- Acceptance criteria clarify the feature and establish clear completion measures
Creating User Stories
User Stories adhere to a specific, predefined structure, and are thus a simplistic way of documenting the requirements, and desired end-user functionality. A User Story tells you three things about the requirement; Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. The predefined, standard format results in enhanced communication among the Stakeholders and better estimations by the Team. Some User Stories may be too large to handle within a single Sprint. These large User Stories are often called Epics. Once Epics come up in the Prioritized Product Backlog to be completed in an upcoming Sprint, they should be decomposed into manageable User Stories.
The Prioritized Product Backlog is a dynamic list that is continuously updated because of reprioritization and new, updated, refined, and sometimes, deleted User Stories. These updates to the Backlog are typically the result of changing business requirements.
As the Customer representative conceives a User Story, it is written down on a note card with a name and a brief description. If the developer and the Customer representative find a User Story deficient in some way (too large, complicated, or imprecise), it is rewritten until satisfactory—often using the INVEST guidelines (see Chapter 8.5 below). Commonly, User Stories should not be considered definitive once they have been written down, since requirements tend to change throughout the development lifecycle, which Agile processes handle by not carving them in stone upfront.
Format for creation of User Story
A useful format for creating a User Story is the following:
"As a <role>, I want <goal/ desire> so that <benefit>".
Here is an example using the format:
As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
User Story Acceptance Criteria
Every User Story has associated Acceptance Criteria. User Stories are subjective, so the Acceptance Criteria provide the objectivity required for the User Story to be considered as Done or Not Done during the Sprint Review. Acceptance Criteria provide clarity to the Team on what is expected of a User Story, remove ambiguity from requirements, and help in aligning expectations. The Product Owner defines and communicates the Acceptance Criteria to the Scrum Team.
In the Sprint Review Meetings, the Acceptance Criteria provide the context for the Product Owner to decide if a User Story has been completed satisfactorily. It is important and the responsibility of the Scrum Master to ensure that the Product Owner does not change the Acceptance Criteria of a committed User Story in the middle of a Sprint.
INVEST criteria for User Stories
The INVEST system features the following characteristics.
| Letter | Meaning |
Description |
| I | Independent | The User Story should be self-contained, in a way that there is no inherent dependency on another User Story. |
| N | Negotiable | User Stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable | A User Story must deliver value to the end user. |
| E | Estimable | You must always be able to estimate the size of a User Story. |
| S | Scalable (small sized) | User Stories should not be so big as to become impossible to plan or task or prioritize with some level of certainty. |
| T | Testable | The User Story or its related description must provide the necessary information to make test development possible. |
1.2.3 Retrospectives
Some facts and some techniques:
- Meet at the end of each iteration
- What worked and what didn’t work so well
- How to improve and how to retain success
- Topics: process, people, organizations, relationships, tools
- Follow through is required
- Essential to self-organization and continual improvement
- Address: test effectiveness/ efficiency, test case quality, team satisfaction, and testability issues
The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required, for the Product Owner to attend. One Team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all Team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right. Primary objectives of the meeting are to identify three specific items:
- Things the Team needs to keep doing—best practices
- Things the Team needs to begin doing—process improvements
- Things the Team needs to stop doing—process problems and bottlenecks
These areas are discussed and a list of Agreed Actionable Improvements is created
Explorer—Shopper—Vacationer—Prisoner (ESVP)
This exercise can be conducted at the start of the Retrospect Sprint Meeting to understand the mind-set of the participants and set the tone for the meeting. Attendees are asked to anonymously indicate which best represents how they feel regarding their participation in the meeting.
- Explorer—Wants to participate in and learn everything discussed in the retrospective
- Shopper—Wants to listen to everything and choose what he takes away from the retrospective
- Vacationer—Wants to relax and be a tourist in the retrospective
- Prisoner—Wants to be elsewhere and is attending the retrospective because it is required
The Scrum Master then collates the responses, prepares, and shares the information with the group.
Speed Boat
Speedboat is a technique that can be used to conduct the Retrospect Sprint Meeting. Team members play the role of the crew on a speedboat. The boat must reach an island, which is symbolic of the project vision. The attendees use sticky notes to record engines and anchors. Engines help them reach the island, while anchors hinder them from reaching the island. This exercise is time-boxed to a few minutes. Once all items are documented, the information is collated, discussed, and prioritized by way of a voting process. Engines are recognized and mitigation actions are planned for the anchors, based on priority.
Metrics and Measuring Techniques
Various metrics can be used to measure and contrast the Team's performance in the current Sprint to their performance in previous Sprints. Some examples of these metrics include:
- Team velocity: Number of Story Points done in a given Sprint
- Done success rate: Percentage of Story Points that have been Done versus those Committed
- Estimation effectiveness: Number or percentage of deviations between estimated and actual time spent on Tasks and User Stories
- Review feedback ratings: Feedback can be solicited from Stakeholder(s) using quantitative or qualitative ratings, providing a measurement of Team performance
- Team morale ratings: Results from self-assessments of Team member morale
- Peer feedback: 360 degree feedback mechanisms can be used to solicit constructive criticism and insight into Team performance
- Progress to release: Business value provided in each release, as well as value represented by the current progress towards a release. This contributes to the motivation of the Team and to the level of work satisfaction.
The outcome of the Retrospect Sprint Meeting
- Agreed Actionable Improvements: Agreed Actionable Improvements are the primary output of the Retrospect Sprint process. They are the list of actionable items that the Team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.
- Assigned Action Items and Due Dates: Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item will have a defined due date for completion.
- Proposed Non-Functional Items for Prioritized Product Backlog: When the initial Prioritized Product Backlog is developed, it is based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings. These items should be added to the Prioritized Product Backlog as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.
- Retrospect Sprint Log: The Retrospect Sprint Logs are records of the opinions, discussions, and actionable items raised in a Retrospect Sprint Meeting. The Scrum Master could facilitate creation of this log with inputs from Scrum Core Team members. The collection of all Retrospect Sprint Logs becomes the project diary and details project successes, issues, problems, and resolutions. The logs are public documents available to anyone in the organization.
- Scrum Team Lessons Learned: The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint. These lessons learned help the Teams improve their performance in future Sprints. These lessons learned may also be documented in Scrum Guidance Body Recommendations to be shared with other Scrum Teams.
There may be several positive lessons learned as part of a Sprint. These positive lessons learned are a key part of the retrospective, and should be appropriately shared within the Team and with the Scrum Guidance Body, as the Teams work towards continuous self-improvement.
- Updated Scrum Guidance Body Recommendations: Because of a Retrospect Sprint Meeting, suggestions may be made to revise or enhance the Scrum Guidance Body Recommendations. If the Guidance Body accepts these suggestions, these will be incorporated as updates to the Scrum Guidance Body documentation.
Retrospect Project
The Retrospect Project Meeting is a meeting to determine ways in which Team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not time-boxed and may be conducted in person or in a virtual format. Attendees include the Project Team, Chief Scrum Master, Chief Product Owner, and Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.
Some of the tools used in the Retrospect Sprint process can also be used in this process. Examples include:
- Explorer—Shopper—Vacationer—Prisoner (ESVP) exercise
- Speed Boat
- Metrics and Measuring Techniques
The outcome of the Retrospect Project Meeting
- Agreed Actionable Improvements: Agreed Actionable Improvements are the primary output of the Retrospect Project Review. They are the list of actionable items that the Team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.
- Assigned Action Items and Due Dates: Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team or Stakeholders. Each action item will have a defined due date for completion.
- Proposed Non-functional Items for Program Product Backlog and Prioritized Product Backlog: When the initial Program Product Backlog or Prioritized Product Backlog are developed, they are based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review, Retrospect Sprint or Retrospect Project Meetings. These items should be added to the Program Product Backlog (for the program) and Prioritized Product Backlog (for the project) as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.
1.2.4 Continuous Integration
Continuous Integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline multiple times a day. It was first named and proposed by Grady Booch in his method, which did not advocate integrating several times a day. It was adopted as part of extreme programming (XP), which did advocate multiple integrations a day, perhaps as many as tens a day. The main aim of CI is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI is not universally accepted as an improvement over daily integration, so it is important to distinguish between the two, as there is disagreement about the virtues of each.
Some key points:
- Merge changes and integrate all code daily (or more often) for quick discovery of defects
- Developers code, debug, and check-in
- Continuous Integration automatically:
- Static code analysis
- Compile
- Unit test (functional/ non-functional)
- Deploy
- Integration test (functional/ non-functional)
- Report
- Automated Continuous Integration, regression testing, and feedback
- Manual testing of new features, changes, and defect fixes
- Some defects are put in the product backlog
Example of Continuous Integration (CI), showing Source Control, Initiate CI Process, Build, Test, Testing, Report, Development, Commit.
Benefits and Risks of Continuous Integration
- Benefits:
- Early defect detection
- Feedback on quality
- Daily test releases
- Lower regression risk
- Confidence and visibility into progress
- No big-bang integration
- Executable software always on tap
- Less repetitive testing
- Quick feedback on process improvements
- Risks:
- The introduction and ongoing use of CI tools may fail
- The CI process may not be adopted by team
- Test automation costs too much or takes too long
- Insufficient skills to create good tests
- Over-reliance on unit tests
- CI process requires tools
1.2.5 Release Planning
Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the Customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing, so that they can align with the expectations of the Product Owner and relevant Stakeholders (primarily the project sponsor).
Release Planning
- Planning is an on-going activity
- For Agile lifecycles: release and iteration planning
- Release planning
- Define product backlog (User Stories for release)
- Refine user epics
- Basis of test approach and test plan for release
- Identify project/ quality risks, estimate effort
- Testers:
- Define testable User Stories
- Participate in project and quality risk analyses
- Estimate test effort
- Plan testing for release
- Release plans may change during project due to internal and external factors
- Testers must handle changes, see larger context of release, and obtain an adequate test basis and test oracles
Many organizations have a strategy regarding release of products. Some organizations prefer continuous deployment, where there is a release after creation of specified usable functionality. Other organizations prefer phased deployment, where releases are made at predefined intervals. Depending on the organization’s strategy, Release Planning Sessions in projects may be driven by functionality, in which the objective is to deliver a release once a predetermined set of functionality has been developed; or the planning may be driven by date, in which case the release happens on a predefined date.
Since Scrum framework promotes information-based, iterative decision making over the detailed upfront planning practiced in traditional waterfall style project management, Release Planning Sessions need not produce a detailed Release Plan for the entire project. The Release Plan can be updated continually, as relevant information becomes available.
Figure: Backlog. Key: Items on Sale. 21. H.
Release Prioritization Methods
Release Prioritization Methods are used to develop a Release Plan. These methods are industry and organization specific and are usually determined by the organization’s senior management.
Release Planning Schedule
A Release Planning Schedule is one of the key outputs of the Conduct Release Planning process. A Release Planning Schedule states which Deliverables are to be released to the Customers, along with planned intervals, and dates for releases. There may not be a release scheduled at the end of every Sprint iteration. At times, a release may be planned after a group of Sprint iterations is completed. Depending on the organization’s strategy, Release Planning sessions in projects may be driven by functionality, in which the objective is to deliver once a predetermined set of functionality has been developed, or the planning may be driven by date, in which case the release happens on a predefined date. The Deliverable should be released when it offers sufficient business value to the Customer.
Iteration Planning
Based on the various inputs, including business requirements and Release Planning Schedule, the Product Owner and the Scrum Team decide on the Length of Sprint for the project. Once determined, the Length of Sprint often remains the same throughout the project.
However, the Length of Sprint may be changed if and when the Product Owner and the Scrum Team deem appropriate. Early in the project, they may still be experimenting to find the best Sprint length. Later in the project, a change in the Length of Sprint normally means it can be reduced due to improvements in the project environment.
A Sprint could be time-boxed for from 1 to 6 weeks. However, to get maximum benefits from a Scrum project, it is recommended to keep the Sprint time-boxed to 4 weeks, unless there are projects with very stable requirements, when Sprints can extend up to 6 weeks.
- Iteration planning
- Define Sprint backlog
- Update test plan
- Select and elaborate User Stories
- Analyze risks for User Stories
- Estimate each User Story, reconcile with team velocity
- Clarify use story with Product Owner
- Assign tasks to the team
- Iteration plans sometimes change
- Testers
- Participate in risk analysis
- Determine testability
- Create acceptance tests
- Create tasks for User Stories
- Estimate test effort
- Define test levels
- Identify functional and non-functional test areas
- Work on test automation
- Communicate with team
- Accommodate changes
Target Customers for Release
Not every release will target all Stakeholders or users. The Stakeholder(s) may choose to limit certain releases to a subset of users. The Release Plan should specify the target Customers for the release.
Refined Prioritized Product Backlog
The Prioritized Product Backlog, developed in the Create Prioritized Product Backlog process, may be refined in this process. There may be additional clarity about the User Stories in the Prioritized Product Backlog after the Scrum Core Team conducts Release Planning Sessions with Stakeholder(s).
