2022

DEVOPS AND AGILE

PROGRAMMING
unit-2
MCA R20 & R21
R Rajendra Prasad
Asst.Professor
MCA Dept

R RAJENDRA PRASAD
JNTUA
3/12/2022
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

Devops and Agile Programming

JNTUA R20 and R21 Regulations

MCA 2 YEAR - I SEM

(2020-21)

DEPARTMENT OF INFORMATION TECHNOLOGY

R. RRAJENDRA PRASAD

Asst. Professor in MCA Dept.

ANANTAPUR 515004

(Affiliated to JNTUA, Anantapur, approved by AICTE - Accredited by NBA & NAAC – ‘A’ Grade - ISO 9001:2015 Certified)

Rudrampeta, Anantapur – 515004, Andhra Pradesh State, INDIA.

https://rajadevops.wordpress.com/mca-materials/ Page 2
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Why do you need Release Management?

In business, every user makes a difference. A blotchy release with bugs and crashes could drive away
potential customers and disappoint existing ones. Frequent downtime and conspicuous bugs could result in
your revenue taking a hit.

Multiple delivery teams often work in parallel in an organization, which can sometimes lead to conflicting
release schedules or dependencies. Establishing a release management process helps your organization
streamline your releases and visualize the big picture across all the teams in your company.

The release management process

Release Management, like software development, progresses in cycles. Whether it's a product launch,
subsequent versions, or a quick update for bug fixes, all releases go through a release management lifecycle.

01. Request for changes or New Features

Whether it's a request for new features for a product or the requirement for a new product, the cycle begins
with identifying the need for changes.

02. Release Planning

All the stakeholders assemble to decide which features get shipped in the next release. Besides the
development team, representatives from Operations and Management should also ideally be included.

03. Software Build

The development team works on building the software based on user stories and acceptance criteria.

https://rajadevops.wordpress.com/mca-materials/ Page 3
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
04. Review

The new software code is reviewed and cleared through quality and security checks. It goes through unit
testing, integration testing, acceptance, and UI testing.

05. Deployment

Sometimes a feature is deployed incrementally—first to internal users of the organization, then to a select
user community, before finally making it available for everyone. These initial users help catch any bugs and
errors so they'll be fixed before the release is deployed to the live environment.

06. Support

The cycle doesn't end as soon as the feature goes live. Marketing and Customer Relations teams coordinate
with developers to create awareness and support material about the new feature for end users.

07. Feedback collection

Customers who reach out with questions or feedback are often the ones actively using your product. Engage
with them to know how your end users perceive a feature and to understand where you can improve. Then,
synthesize the collected feedback to create actionable work items for the next release.

Release management in Agile

The Agile approach to release management is called continuous development. Continuous development is
the ability to get changes of all types—such as new features, configuration changes, bug fixes, and
experiments—into production or into the hands of users safely and quickly in a sustainable way. Just as in
the Agile development process, releases also consist of small bundles of high-priority, high-value features
(or sometimes a single feature). So agile teams have smaller and more frequent releases than traditional
ones.

Continuous integration

The practice of continuous integration advises developers to merge their code with the main repository as
often as possible. An automated build is extracted for each check-in and goes through automated test cases,
which helps catch integration errors early. This ensures the main code branch stays updated at all times. The
benefits of an effortless release without the integration hassles outweigh the costs of setting up automated
tests.

Continuous delivery

While continuous integration places emphasis on automated testing, continuous delivery goes a step further
to automate your release process. This means you can release to your customers any time your business
requires it—reliable releases in a quick and sustainable way. The release process is automated right up to the
point where the release is deployed.

With this practice, the code is release-ready almost all the time. This reduces the coordination, efforts, and
stakes associated with each release. You only need a manual trigger.

https://rajadevops.wordpress.com/mca-materials/ Page 4
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Continuous deployment

With continuous deployment, the entire process is automated, including the actual deployment of your code.
All the commits go through automated testing and are released automatically to the production environment.
A code change is held back only when it fails the quality review. Since new changes are made available to
end users with almost no human buffer in the middle, continuous deployment requires post-release
monitoring to catch any bugs that may have slipped through the automated tests.

The three practices of Continuous Software Development

Continuous Integration is about developing and testing code with automation, ensuring only good code
becomes a part of the software product. Teams practicing continuous delivery extract builds for each
commit, verify it using automated testing, and have it ready to deploy at any time. They can then choose to
release according to their business requirements. Continuous deployment means the team actually deploys
continuousl with no human involvement in the release process.

These three practices together are called continuous software development and are associated with Agile
methodologies and DevOps. All of these effectively accelerate the software release cycle and help Agile
teams ship reliable software frequently in a sustainable way.

Role of a Release Manager

As the name suggests, the release manager oversees the entire release management process and is constantly
working to improve it. They're aware of the complexities in development and operations, and act as a
catalyst in coordinating the different teams and departments involved in a release.

They are adept at managing time, money, and people. Managing a release is fairly similar to managing a
project, so it's crucial release managers possess project management skills as well.

Release management best practices

Maintain a prioritized Scrum backlog

Ensure your backlog is prioritized at all times. This eliminates any confusion during the release-planning
meeting. Having a concrete to-do list gives your team a transparent view of what's planned for the next
release and what they'll be working on in the upcoming ones.

Create a release checklist

An exhaustive checklist of things to double-check before a release can help eliminate a lot of human errors.
It adds a final level of security which can catch fine details that are likely to be overlooked.

https://rajadevops.wordpress.com/mca-materials/ Page 5
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Triage your feedback

All through your release cycle, you will get feedback from different channels—stakeholders, customers, or
internal users. This feedback offers a starting point for enhancements or new features. Sort the barrage of
feedback based on criticality and relevance to avoid getting overwhelmed or misled by them.

Identify metrics for observation

To understand the impact of a release, it's important to identify relevant metrics and monitor them
continuously. Standard release reports about downtime, type and priority of releases, and number of on-time
releases can yield valuable insights about the work dynamic of your team.

What is a Bug in Agile?

In software, a malfunction of the system, an error, flaw, or a default in the system, that causes an incorrect
result. A bug is when the system doesn’t behave as intended.

The bugs identified for missing functionalities I recommend there are new user stories written, not a bug. The
bugs should be for faulty behavior.

Agile Bugs classification

We can classify the bugs by the moment when they were identified: in production, in development (user
stories in the current sprint).

The bugs reported in production need to have assigned a priority:

1. High priority bug — in this category, we consider the bugs that the core functionalities of the product.
For example, for a car software product, an issue that doesn’t allow the user to drive its car will be a high
priority bug.
2. Medium priority bug — there is a workaround available. For example, I am opening a car with the key
instead of pressing the open button of the key. Unlocking the vehicle is a core function of the car, but
since there is a workaround available, the bug will be a medium priority.
3. Low priority bug — the issue is rather cosmetic or comfort, with no critical functionality.

Defining the classification of the bugs helps for the fast sorting of the defects.
The product owner can decide quickly which ones get on the teams’ sprint
and which bugs to add to the product backlog.

We could have operational teams and product teams. This article

concerns the product teams that do both maintenance of the production product but also the new
development of the product.

Do we add user stories to the Bugs in Agile?

There are two scenarios: you can either timebox the time spent on bugs or refine them and assign story points.
Let’s have a close look at the options:

Scenario 1: Assign the timebox to the bugs. The team assigns a fixed number of hours dedicated to the
bugs, takes them one by 1 to treat them from the top priority of the list. In this scenario, the team can handle

https://rajadevops.wordpress.com/mca-materials/ Page 6
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
one bug or five or an unlimited amount of bugs. There is no prediction on how many bugs the team can do
and no commitment to the delivery time. But, at the same time, there is no time lost on investigating the bugs.

Scenario 2: Refine the bugs and estimate them in user stories. For clarification, the bugs are the
misfunctioning of the product. Functionalities that aren’t present in the product, they must be handle with
user stories, not with bugs. The nature of the flaws in software is very uncertain: they can take a few minutes,
as they can make an unestimated amount of time. It might take more effort to find the root cause of a bug
than actually fixing it. If you want to estimate a bug, you first need to investigate the issue, look into the code,
debug, isolate the problem. If the team spends this effort during the refinement processes and the entire team
is involved, it might be a waste of team effort.

I recommend the bugs aren’t estimated but sorted using the priority definition, assigned to the team backlog,
and then directly fixed. Any time spent on investigating the flaws is a waste, and most of the time cannot be
estimated.

Counting bugs in Scrum team velocity

Above we clarified that the team should not assign story points to the flaws because estimating bugs is a
waste of team effort.

By default, velocity means progress, new functionalities that are being developed. A bug is repairing the
existing functionality that is faulty. Adding story points when fixing bugs leads to inflation. The team takes
credit twice for the same work: one time for developing the functionality and one time for fixing its defects or
the complete delivery. This behavior leads the team to do not be that carefully and introducing bugs. In
scrum, we do not count story points for defects. We work to minimize the effort spent on bugs or to keep it
constant.

How do we deal with urgent bugs in Agile?

Every time I start working with a new client, my answer to this question is: define first the priorities (see list
above), and I strongly recommend the tribes to fix the urgent bugs.

While this is a temporary solution to stop a fire, it is the worst long term strategy. Must the bugs be
minimized? The user story must contain all the effort involved from creation to production. It includes
development, peer review, testing, Product Owner acceptance, integration testing, deployment to the right
environment. Only when the entire circle is closed, we can know if the functionality meets the business
requirements or not. If the full testing is not part of the user story, then we have a fake velocity. We measure
the coding, but not if it did the final customer can use it. For the whole Agile methodology to work, testing
must be part of the development of the user story and the velocity.

How to minimize the Agile bugs in your product?

 Increase the code quality respecting the industry benchmarks

 Respect the definition of done and try to bring the user story as close to the production candidate as
possible
 Try to identify the bugs early with unit testing, peer review, product owner acceptance. The team fixes
any bug found in the early stage of the user story development during the sprint.

What is version control?

https://rajadevops.wordpress.com/mca-materials/ Page 7
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
How version control helps high performing development and DevOps teams prosper

Version control, also known as source control, is the practice of tracking and managing changes to software
code. Version control systems are software tools that help software teams manage changes to source code
over time. As development environments have accelerated, version control systems help software teams
work faster and smarter. They are especially useful for DevOps teams since they help them to reduce
development time and increase successful deployments.

Version control software keeps track of every modification to the code in a special kind of database. If a
mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the
mistake while minimizing disruption to all team members.

For almost all software projects, the source code is like the crown jewels - a precious asset whose value must
be protected. For most software teams, the source code is a repository of the invaluable knowledge and
understanding about the problem domain that the developers have collected and refined through careful
effort. Version control protects source code from both catastrophe and the casual degradation of human error
and unintended consequences.

Software developers working in teams are continually writing new source code and changing existing source
code. The code for a project, app or software component is typically organized in a folder structure or "file
tree". One developer on the team may be working on a new feature while another developer fixes an
unrelated bug by changing code, each developer may make their changes in several parts of the file tree.

Version control helps teams solve these kinds of problems, tracking every individual change by each
contributor and helping prevent concurrent work from conflicting. Changes made in one part of the software
can be incompatible with those made by another developer working at the same time. This problem should
be discovered and solved in an orderly manner without blocking the work of the rest of the team. Further, in
all software development, any change can introduce new bugs on its own and new software can't be trusted
until it's tested. So testing and development proceed together until a new version is ready.

Good version control software supports a developer's preferred workflow without imposing one particular
way of working. Ideally it also works on any platform, rather than dictate what operating system or tool
chain developers must use. Great version control systems facilitate a smooth and continuous flow of changes
to the code rather than the frustrating and clumsy mechanism of file locking - giving the green light to one
developer at the expense of blocking the progress of others.

Software teams that do not use any form of version control often run into problems like not knowing which
changes that have been made are available to users or the creation of incompatible changes between two
unrelated pieces of work that must then be painstakingly untangled and reworked. If you're a developer who
has never used version control you may have added versions to your files, perhaps with suffixes like "final"
or "latest" and then had to later deal with a new final version. Perhaps you've commented out code blocks
because you want to disable certain functionality without deleting the code, fearing that there may be a use
for it later. Version control is a way out of these problems.

Version control software is an essential part of the every-day of the modern software team's professional
practices. Individual software developers who are accustomed to working with a capable version control
system in their teams typically recognize the incredible value version control also gives them even on small
solo projects. Once accustomed to the powerful benefits of version control systems, many developers
wouldn't consider working without it even for non-software projects.

https://rajadevops.wordpress.com/mca-materials/ Page 8
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

Benefits of version control systems

Using version control software is a best practice for high performing software and DevOps teams. Version
control also helps developers move faster and allows software teams to preserve efficiency and agility as the
team scales to include more developers.

Version Control Systems (VCS) have seen great improvements over the past few decades and some are
better than others. VCS are sometimes known as SCM (Source Code Management) tools or RCS (Revision
Control System). One of the most popular VCS tools in use today is called Git. Git is a Distributed VCS, a
category known as DVCS, more on that later. Like many of the most popular VCS systems available today,
Git is free and open source. Regardless of what they are called, or which system is used, the primary benefits
you should expect from version control are as follows.

1. A complete long-term change history of every file. This means every change made by many individuals over
the years. Changes include the creation and deletion of files as well as edits to their contents. Different VCS
tools differ on how well they handle renaming and moving of files. This history should also include the
author, date and written notes on the purpose of each change. Having the complete history enables going
back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix
problems in older versions of software. If the software is being actively worked on, almost everything can be
considered an "older version" of the software.
2. Branching and merging. Having team members work concurrently is a no-brainer, but even individuals
working on their own can benefit from the ability to work on independent streams of changes. Creating a
"branch" in VCS tools keeps multiple streams of work independent from each other while also providing the
facility to merge that work back together, enabling developers to verify that the changes on each branch do
not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for
each release, or both. There are many different workflows that teams can choose from when they decide
how to make use of branching and merging facilities in VCS.
3. Traceability. Being able to trace each change made to the software and connect it to project management and
bug tracking software such as Jira, and being able to annotate each change with a message describing the
purpose and intent of the change can help not only with root cause analysis and other forensics. Having the
annotated history of the code at your fingertips when you are reading the code, trying to understand what it
is doing and why it is so designed can enable developers to make correct and harmonious changes that are in
accord with the intended long-term design of the system. This can be especially important for working
effectively with legacy code and is crucial in enabling developers to estimate future work with any accuracy.

While it is possible to develop software without using any version control, doing so subjects the project to a
huge risk that no professional team would be advised to accept. So the question is not whether to use version
control but which version control system to use.

https://rajadevops.wordpress.com/mca-materials/ Page 9
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
The types of VCS are:

 Local Version Control System

 Centralized Version Control System
 Distributed Version Control System

Local Version Control System

A local version control system is a local database located on your local computer, in which every file change
is stored as a patch. Every patch set contains only the changes made to the file since its last version. In order
to see what the file looked like at any given moment, it is necessary to add up all the relevant patches to the
file in order until that given moment.

The main problem with this is that everything is stored locally. If anything were to happen to the local
database, all the patches would be lost. If anything were to happen to a single version, all the changes made
after that version would be lost.

Also, collaborating with other developers or a team is very hard or nearly impossible.

https://rajadevops.wordpress.com/mca-materials/ Page 10
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Centralized Version Control System

A centralized version control system has a single server that contains all the file versions. This enables
multiple clients to simultaneously access files on the server, pull them to their local computer or push them
onto the server from their local computer. This way, everyone usually knows what everyone else on the
project is doing. Administrators have control over who can do what.

This allows for easy collaboration with other developers or a team.

The biggest issue with this structure is that everything is stored on the centralized server. If something were
to happen to that server, nobody can save their versioned changes, pull files or collaborate at all. Similar to
Local Version Control, if the central database became corrupted, and backups haven't been kept, you lose
the entire history of the project except whatever single snapshots people happen to have on their local
machines.

The most well-known examples of centralized version control systems are Microsoft Team Foundation
Server (TFS) and SVN.

https://rajadevops.wordpress.com/mca-materials/ Page 11
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Distributed Version Control System

With distributed version control systems, clients don’t just check out the latest snapshot of the files from the
server, they fully mirror the repository, including its full history. Thus, everyone collaborating on a project
owns a local copy of the whole project, i.e. owns their own local database with their own complete history.
With this model, if the server becomes unavailable or dies, any of the client repositories can send a copy of
the project's version to any other client or back onto the server when it becomes available. It is enough that
one client contains a correct copy which can then easily be further distributed.

Git is the most well-known example of distributed version control systems.

10 Minute Build For Agile/ Scrum

The 10 Minute Build is the gold standard for getting what, in Agile/Scrum, we call Fast Feedback. With the
click of a button, you should be able to build your software, run comprehensive automated tests, and deploy
to a testing environment.

This matters. It allows the team to “fail fast”.

Fast Feedback

Agile/Scrum emphasises the importance of feedback loops, for example our Daily Scrums and Sprints.
These ceremonies provide rapid information to the Team as to the status of User Stories, and, hence, the
https://rajadevops.wordpress.com/mca-materials/ Page 12
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
progress of the product. Adding a 10 Minute Build to your toolkit can greatly enhance the speed of
information and the acceptance of User Stories.

When a Feature or User Story can be put in front of the Product Owner and stakeholders within minutes,
feedback, acceptance, or rejection, can be given to the team in near real time. Agile/Scrum moves pretty fast,
but our 10 Minute Build means that when Sprint Review rolls around our Stories have a higher acceptance
rate. Fast Feedback has helped reduce the amount of Undone work, meaning we hit more of our targets.

Another consequence of our 10 Minute Build is that we minimise the amount of In Progress User Stories in
our Sprints. Team members can often get Fast Feedback before they get too deep into other User Stories.

Any ScrumMaster will tell you that In Progress is toxic; a very common cause of failed Sprints.

Building in quality from the beginning

I’ve built and shipped a few SaaS products using Agile/Scrum, but with Cyclr this was the first “blank page”
that I was able to approach as a Product Owner. Previous projects sometimes felt like Agile/Scrum was
adapted for a process rather than adopted (not uncommon!). With Cyclr we invested time and effort upfront
in engineering to give us:

 Continuous Integration (we use Jenkins)

 Automated Build (asynchronous on an AWS instance)
 Automated Deployment (we use Octopus)

Here’s our current process:

 A developer merges code to our development branch on Github

 A webhook pings Jenkins, who picks up the branch and triggers the build
 Octopus deploys the build to the development servers
 Jenkins posts a message on our /builds Slack channel announcing the deployment and build status
 Product Owner and stakeholders review the build
 High fives or real tears…

One of the biggest lessons we took from our 10 Minute Build was the need to integrate often, ensuring that a
development branch didn’t drift too far. Complex merges are much more likely to snag on regression tests,
meaning a higher frequency of failed builds.

If your software doesn’t have a 10 Minute Build, I definitely recommend you start to work towards one. It
will tighten up your entire Agile/Scrum process and so help ensure you deliver better quality software on
time.

Continuous Integration Explained

Continuous integration is a DevOps software development practice where developers regularly merge their
code changes into a central repository, after which automated builds and tests are run. Continuous
integration most often refers to the build or integration stage of the software release process and entails both
an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate

https://rajadevops.wordpress.com/mca-materials/ Page 13
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
frequently). The key goals of continuous integration are to find and address bugs quicker, improve software
quality, and reduce the time it takes to validate and release new software updates.

Why is Continuous Integration Needed?

In the past, developers on a team might work in isolation for an extended period of time and only merge
their changes to the master branch once their work was completed. This made merging code changes
difficult and time-consuming, and also resulted in bugs accumulating for a long time without correction.
These factors made it harder to deliver updates to customers quickly.

How does Continuous Integration Work?

With continuous integration, developers frequently commit to a shared repository using a version control
system such as Git. Prior to each commit, developers may choose to run local unit tests on their code as an
extra verification layer before integrating. A continuous integration service automatically builds and runs
unit tests on the new code changes to immediately surface any errors.

Continuous integration refers to the build and unit testing stages of the software release process. Every
revision that is committed triggers an automated build and test.

With continuous delivery, code changes are automatically built, tested, and prepared for a release to
production. Continuous delivery expands upon continuous integration by deploying all code changes to a
testing environment and/or a production environment after the build stage.

Run tests locally

CI is intended to be used in combination with automated unit tests written through the practices of test-
driven development. This is done by running and passing all unit tests in the developer's
local environment before committing to the mainline. This helps avoid one developer's work-in-progress
breaking another developer's copy. Where necessary, partially complete features can be disabled before
committing, using feature toggles for instance.

Compile code in CI

A build server compiles the code periodically or even after every commit and reports the results to the
developers. The use of build servers had been introduced outside the XP (extreme programming) community
and many organisations have adopted CI without adopting all of XP.

https://rajadevops.wordpress.com/mca-materials/ Page 14
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Run tests in CI

In addition to automated unit tests, organisations using CI typically use a build server to
implement continuous processes of applying quality control in general – small pieces of effort, applied
frequently. In addition to running the unit and integration tests, such processes run additional static analyses,
measure and profile performance, extract and format documentation from the source code and facilitate
manual QA processes. On the popular Travis CI service for open-source, only 58.64% of CI jobs execute
tests.

This continuous application of quality control aims to improve the quality of software, and to reduce the
time taken to deliver it, by replacing the traditional practice of applying quality control after completing all
development. This is very similar to the original idea of integrating more frequently to make integration
easier, only applied to QA processes.

Deploy an artifact from CI

Now, CI is often intertwined with continuous delivery or continuous deployment in what is called CI/CD
pipeline. "Continuous delivery" makes sure the software checked in on the mainline is always in a state that
can be deployed to users and "continuous deployment" makes the deployment process fully automated.

Collective Code Ownership in Agile Teams

There are two types of software development teams, ones that follow individual code ownership and ones
that follow collective code ownership.

It is never a straight-forward decision to choose between the two as there are positives and negatives within
both approaches. In this post, we discuss the strengths and weakness of collective code ownership.

Collective Code Ownership

In collective code ownership, the entire team is responsible for the code. Everyone works together to
produce a product of quality. No one individual is greater than the rest of the team members. This is what
the true Agile teams are supposed to be.

We have experienced that collective code ownership is better in the long run.

Let's look at the various factors that helped us come to this conclusion.

Benefits of Collective Code Ownership

Knowledge Sharing

When only one individual is responsible for certain modules or features, a knowledge-silo builds up. This
leads to critical knowledge being confined to a smaller group of people or, even worse, to an individual.

When the team is collectively responsible for the code, everybody learns. With more people having the
knowledge to make a difference, the product quality is bound to improve.

https://rajadevops.wordpress.com/mca-materials/ Page 15
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Code Quality and Better Coding Style

With many people contributing to the code, it will result in better overall quality of the code. Of course, this
is assuming that they care about improving the code. With only one person coding in a module, there will
not be any constructive criticism of the work carried out.

Let us not ignore the coding style–each person has a different style, some more understandable than others,
some better and more efficient than others. When the team contributes to the code, it will evolve without
leaning to an individual’s coding style and hence more comprehensible to a wider set of people.

No Dependency on One Individual

This is sometimes referred to as the “bus effect” or the “lottery effect." As a humorous example, what if the
individual responsible for your code wins the lottery and quits the company? Will the team struggle? If yes,
that’s one reason to start giving responsibilities to the the team collectively.

Efficient and Useful Code Reviews

When no one else other than one person knows about the code within a feature or a module, the code
reviews become a farce. Aside from being able to make abstract comments at a high level, real
improvements cannot be suggested.

On the other side, when everyone in the code review is more familiar with the code, the reviews are highly
beneficial with everyone contributing to the code review, different ideas and improvements come to the
discussion and optimal solutions can be chosen.

Great Learning Scope

Most people stagnate in terms of their skills development if they do the same work over again. One way this
happens is when companies create specialized roles and responsibilities with in the development team.

It is continuous learning that keep the developer’s skills sharp and the mind active. With constant
interactions and discussions with better developers, one can learn a lot in a short period of time.

Agile/Scrum Principles

Collective responsibilities and interaction are what Agile is all about. The teams with collective
responsibilities tend to be more adept at sticking to the Agile principles than ones that don’t for the
following reasons.

1. Collective code ownership automatically results in a self-organizing team.

2. As per Scrum, it is the individual team members that should pick the work of their choice. It should
never be assigned before hand to a particular person or a role.
3. Estimation of efforts should happen from everyone’s input. No one person should have a majority
say in the estimation process.

Negatives of Collective Ownership

With all the positives of collective code ownership, one might conclude that it is no brainier to go with that
approach. While that is true in most cases, it is worthwhile to consider the following aspects.

https://rajadevops.wordpress.com/mca-materials/ Page 16
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
1. Who is Responsible?

Unless the team consists of individuals that are responsible by nature, collective ownership will result in no
ownership. A quote comes to my mind.

2. Responsibilities and Motivation

If there is one thing that separates successful people from mediocre ones, it is that successful ones always
want more responsibility. They are never the ones to just do their job and go home. They want to improve
things further, their passion makes them go the extra mile.

If the more skilled developers are not given more responsibilities or challenges, it will demotivate them. It is
a knife’s edge that separates democracy vs individual brilliance.

3. Team’s Technical Capability

The team’s technical capability will play a huge role in whether collective ownership will sustain for the
length of the project, or whether the project will be successful at all. A group of mediocre or poor
programmers will not achieve good results. It is better instead for more skilled person to be making the
important decisions on behalf of the team, to govern and monitor the work done by others.

4. Specialization vs. Generalization

In extremely complex products, specialized people are hired to carry out specific functions. For example,
consider a team consisting of business intelligence specialist, big data expert, security expert and a mobile
application developer. There is no possibility that each person here could do the other person’s job. In such
teams, collective ownership would be impossible and should not be enforced as well.

Agile Documentation – 6 Efficiency Hacks for Agile Projects’ Documentation

Agile documentation is an approach to create concise documents that serve the situation at hand. In
traditional software development projects, there is comprehensive documentation which is perceived as a
risk reduction strategy.

https://rajadevops.wordpress.com/mca-materials/ Page 17
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
In agile projects, a high level of documentation increases the overall project risk as it lowers down the
adaptability to changes.

The documentation should be as efficient as possible in a way it achieves relevant goals in agile software
development projects. In this article, you will find 6 hacks that will guide you while creating documents for
your agile projects.

1) Work with executable specifications

In traditional software development projects, there are specification documents such as requirement
specification, architecture specification, or designs specification. In an agile project, there are executable
specifications in the form of tests.

In this Test Driven Development (TDD), you take a Just-In-Time (JIT) approach to write the detailed
specifications. There is a Single Source Information that is the test to outline the
requirements/architecture/design and validate your work.

2) Document as late as possible

As a part of the agile strategy, you document as late as possible, only before you require them. This practice
is known as “document late” that means the best time to write system overviews will be towards the end of
the development of a release.

This way you document what you have actually built. The majority of the user and support documentation is
pushed to the end of the lifecycle to ensure high quality. You still take notes throughout the development for
capturing critical information that will help to formulate the documents at the end.

3) Simplify documentation

In agile documentation approach, one core principle followed is that the comprehensive documentation
doesn’t give surety of the project success. Rather it could lead to failure. So the Agile Modeling (AM)
practices are followed to use the simplest tools, to create simple content and to depict models simply.

This means rather than writing a document with 50 pages, a 5-page document with bullet points can be good
enough to provide a useful context.

The higher the number of pages in the document, the higher would be the chances of error. A short and
concise document is easier to maintain and lesser prone to errors. In the agile documents, the high-level
overview may not have detailed information but it does provide a map to dive in the source code.

4) Avoid overlapping documents

The documentation should be just good enough to serve the purpose of dealing with the situation at hand.
This requires building larger documents from smaller ones. You can create Wikis sort of documentation to
create different single pages for single topics.

For example, you can have a single page describing the user interface architecture. There can be a single
page to describe the user interface flow diagram. A table of contents pages for the system documentation
and system guides. This will also ensure that there is no overlap of information.

https://rajadevops.wordpress.com/mca-materials/ Page 18
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
5) Purpose oriented documents

In an agile project, you should only create a document to cater to some immediate goal of your project. In
the case of documentation, one size never fits all. Each system has its own unique documentation needs that
also mean you cannot reuse the repeatable process to create documents.

Start with identifying the potential users of your document. After identifying the users, discuss with them
their needs and negotiate with them to agree upon a minimal subset of documentation they will actually
need.

6) Ensure good communication

Good communication is essential for understanding rather than documentation. The agile documentation
supports the maintenance developers to understand how the system works so that they can evolve it over
time. There is no use of documenting things which will not be of any use.

The purpose of agile documents is to help the support and operations staff with easy to understand, concise
information. Documentation that facilitates knowledge transfer is only possible when effective
communication with all the project stakeholders is there throughout the project.

Agile Planning
Planning is an inevitable part of everyone's day-to-day activities; whether it relates to weekly shopping for
household goods or routine office work. Think about the months of planning that went into organizing a trip
to your favorite destination! Each scenario requires some planning, but at different scales.

Let's take this planning and apply it to the field of Agile Software Development. In Agile, there are multiple
levels of planning based on the scale and size of the requirements and the defined timeframe.

The requirements, also called Backlogs can come from many stakeholders like the Business, Product Owner
or even the Teams. Some of the requirements could be a small enhancement or functional addition to the
product that can be completed in an iteration. In case of Backlogs that are bigger in size and cannot fit into
one iteration, it can be split into two or more User Stories that are planned into multiple iterations. It is said
that your User Story should be small enough to fit into a 'Sticky Note'. Larger backlog items, will be
identified as features and these deliver business value to the customers. These features are further broken
down into stories that are planned in multiple iterations. At the end of every release, these features, in the
form of a working software is delivered and validated. This may or may not really involve multiple Agile
teams.

Enterprises usually have many portfolios with many products. There can be large scale requirements, or
initiatives like a new product idea itself, which may involve multiple teams and iterations. But how do you
handle such large scale initiatives that span across multiple iterations? This requires lot of planning! But
hey, in Agile doing upfront planning and design is a big 'No', right?

To counter this, Agile itself suggests 5 levels of planning for such large scale development

https://rajadevops.wordpress.com/mca-materials/ Page 19
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

1. Product Vision

Product Vision is the long term outcome that the product aims for. All teams align their work to ensure that
the ultimate goal and finally, the vision is met. Say, there is an Amusement Park, 'La La Land' with a vision
statement: 'To be the 'Go-To' place in entertainment for family and friends in the country in the next three
years (20XX)'. This will define the ultimate goal for all 'La La Land' employees.

2. Roadmap

Roadmap is a plan on how the product should evolve to achieve the above vision. The 'La La Land'
stakeholders will create a roadmap, which clearly depicts the plan with milestones, defining the steps that
will help the enterprise move closer to the goal. A roadmap for the above example could be, by next quarter,
finalize cities across the country, where multiple amusement parks could be set up and so on.

3. Release Plan

The Release Plan defines the list of features that will be delivered in the decided timeline. As per the
Roadmap, 'La La Land' has plans to launch its branches in top cities of India. As part of its first release, the
'La La Land' team plans to launch rides in Chennai and Mumbai and decides on marketing campaigns and
events to be conducted in these cities to popularize the brand.

4. Iteration Plan

During Iteration Planning, teams commit to deliver a set of product backlogs. In order to launch the 'La La
Land' branch in Chennai, the Chennai team decides to purchase a Giant Wheel and few Dashing Cars in the
next fortnight.

5. Daily Standup

The Daily Standup is where the entire team meets. This usually happens at the start of the day, where each
team member shares details on:

 What was done yesterday?

 What are the plans for today?

https://rajadevops.wordpress.com/mca-materials/ Page 20
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
 Any impediment/issues that are currently being faced. This will be highlighted so that the Scrum
Master can help to resolve the issues quickly.

For small products, you may just need the Iteration Planning and Daily Standup.
Therefore, based on the Requirements (Backlogs) size, you may apply few or all the levels of planning as
per the need. As Agile teams, let's continue rolling value to our customers and have happy users and happy
us at the end.

Vision
The Vision is a description of the future state of the Solution under development. It reflects customer and
stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.

The vision is both aspirational and achievable, providing the broader context—an overview and purpose—of
the Solution under development. It describes the markets, customer segments, and user needs. It sets the
boundaries and context for new Features, Nonfunctional Requirements (NFRs), and other work.

The vision applies to any SAFe configuration, which explains why it’s on the Spanning Palette. While its
focus is typically on the solution, a portfolio vision is also clearly relevant, reflecting how Development
Value Streams will cooperate to achieve the Enterprise objectives. Agile Release Trains (ARTs) and Agile
Teams may also have their own vision to communicate their part in developing the solution.

Few question the benefit of Lean-Agile’s focus on near-term deliverables and fast value delivery, which
favors deferring decisions until the last responsible moment and limiting Work in Process (WIP). It also
avoids Big Design Upfront (BDUF), future-proofing architectures, and overly detailed plans. There is no
substitute for a bias for action. (“Let’s build it, and then we’ll know.”)

However, in the context of large solutions, every individual contributor makes many decisions. Therefore,
continuously developing, maintaining, and communicating the vision is critical to creating a shared
understanding of the program’s goals and objectives, especially as those ideas evolve due to ever-shifting
market needs and business drivers.

Portfolio Vision

In Portfolio SAFe, The portfolio vision sets a longer-term context for near-term decisions in a way that is
both practical and inspirational. (“This is something worth doing.”) Understanding the longer-term view
helps the Agile teams make more informed choices about the development of functionality in both the short
and long run.

The Portfolio canvas is a key input in developing the portfolio vision. One of the primary uses of the canvas
is to record the current state of the portfolio. The current state canvas represents the as-is state for the
portfolio, enabling alignment of the organization on its structure, purpose, and status. The next step is to
envision the future state, which helps define the vision for the portfolio.

Lean-Agile Leaders have the most responsibility for setting the strategic direction of the company and
establishing the mission for the teams who will implement that strategy. Switch calls this view a
“Destination Postcard,” as Figure 1 illustrates [1].

https://rajadevops.wordpress.com/mca-materials/ Page 21
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

Figure 1. The portfolio vision is an enterprise-level ‘postcard from the future.’

A portfolio vision exhibits the following characteristics:

1) Aspirational, yet realistic and achievable – It must be compelling and somewhat futuristic, yet practical
enough to be feasible over some meaningful timeframe

2)Motivational to engage others on the journey – The vision must align with the Strategic Themes, as
well as to the individual team’s purpose

Business Owners (or C-level executives) typically present this longer-term view and business context during
the Program Increment (PI) Planning event. These leaders can inspire and align the teams, increasing their
engagement and fostering their creativity to achieve the best results.

Solution Vision

In Large Solution SAFe, Product and Solution Management have the responsibility for translating the
portfolio vision to a solution vision, indicating the reason and direction behind the chosen solution. Doing so
requires specific questions to be asked and answered:

 What will this new solution do?

 What problems will it solve?
 What features and benefits will it provide?
 For whom will it provide them?

https://rajadevops.wordpress.com/mca-materials/ Page 22
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
 What Nonfunctional Requirements will it deliver?

Inputs to the Solution Vision

Product and Solution Management work directly with Business Owners and other stakeholders to
synthesize all the inputs and integrate them into a holistic and cohesive vision, as Figure 2 illustrates.
These inputs include the following resources:

Figure 2. Solution vision input sources

Customers – Customers provide fast feedback and have intimate knowledge of what is needed

 Strategic Themes – The Strategic Themes provide direction and serve as decision-making filters
 Portfolio Canvas – The portfolio canvas provides the current state and the desired future state for the
portfolio Solution Context – The solution context indicates how the solution interacts with the
customer’s context
 Solution Backlog – The solution backlog contributes direction and guidance to the vision
 Solution Intent – The solution intent contains some of the vision and is the destination for new
elements Architect/Engineers – The System and Solution Architect/Engineers support the continuous
evolution of the Architectural Runway supports current and near-term features
 Agile Teams– Finally, and not to forget the obvious, the foremost experts in the domain are typically
the Agile teams themselves

https://rajadevops.wordpress.com/mca-materials/ Page 23
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
 Product Owners – The Product Owners continuously communicate emerging requirements and
opportunities back into the program vision.
Capturing Vision in Solution Intent

Given the SAFe practice of cadence-based, face-to-face PI planning, vision documentation (various forms of
which can be found in [2], [3], and [4]) is augmented and sometimes replaced, by rolling-wave vision
briefings. These provide routine, periodic presentations of the short- and longer-term vision to the teams.
During PI planning, stakeholders building large solutions, such as Solution Management, describe the
current overall solution vision, while Product Management provides the specific Agile Release Train (ART)
context and vision.

The relevant elements of the vision, along with details of the current and specific behaviors of the system,
are captured in solution intent.

Program Vision

When using Full SAFe or Large Solution SAFe, each ART will likely have its own vision, detailing the
direction of the specific capabilities or subsystems that it produces. This vision should be tightly coupled to
the solution vision it supports.

Roadmap View

Having a sense of direction is critical to planning and engagement. But unless there is some realistic plan for
how teams intend to fulfill the vision, people won’t actually know what they must do. That purpose is filled
by the Roadmap. Figure 3 provides an example.

https://rajadevops.wordpress.com/mca-materials/ Page 24
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

Figure 3. The Roadmap is part of the vision

PI Planning Vision—the Top 10 Features

The roadmap is indeed helpful. But for action and execution, the immediate steps must be clear. Product and
Solution Management have the responsibility to provide the direction for these next steps. In the SAFe
context, this translates to a series of increment steps forward, one PI at a time and one feature at a time, as
Figure 4 illustrates.

Figure 4. Vision is achieved one PI at a time, via the “Top 10 Features for the next PI”

https://rajadevops.wordpress.com/mca-materials/ Page 25
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
To achieve this, Product Management constantly updates feature priorities using Weighted Shortest Job First
(WSJF). Then, during PI planning, they present the top 10 to the team. The team won’t be surprised by the
new list, as they have seen the vision evolve over time and are aware of the new features that are headed
their way. Further, the Program Kanban is used to explore the scope of features, their benefit hypotheses,
and acceptance criteria, so when features reach this boundary, they are fairly well-formed and vetted.
Architect/Engineering has already reviewed them, and various Enablers have already been implemented.

However, everyone understands that the top 10 is an input, not an output to the planning process, and what
can be achieved in the next PI is subject to capacity limitations, dependencies, the knowledge that emerges
during planning, and more. Only the teams can plan and commit to a course of action, one that is
summarized in the PI Objectives.
But these features are ready for implementation. And feature by feature, the program marches forward
toward the accomplishment of the vision.

What is Agile release planning?

Agile release planning is a product management method where you plan incremental releases of a product. It
differs from traditional software planning where you focus on major releases.

In Agile release planning, you prepare for staged releases and then break those down into several different
sprints or iterations. Depending on your team structure and the size of the project, you may even have
several sprints running at the same time.

A sprint ends with a new product increment, but that may not mean a product release happens. Think about
writing a book — each sprint should end with a new draft. But, just because you have a finished draft for
your client (editor, publisher, etc.) to review doesn’t mean you release it to the public.

You might create versions 1.1, 1.12, 1.14, 1.2, and so on, each one incorporating the new features and
improvements of the last. But you’ll only release the big ones (1.1 and 1.2, etc.)

Using a release plan helps you plan which product increments (versions) get released to the market and
when. And it’s an integral part of the Agile SDLC (Software Development Life Cycle) because it can also
give higher-ups peace of mind that there’s a structure and plan beyond just the next sprint, and helps the
individual Agile teams stay on track.

A release plan outlines immediate future releases but doesn’t try to plan for years to come, but it also is
unique from a product roadmap (high-level scope and timeline) because it goes into more detail. However,
an Agile release plan doesn’t outline the work in each release. Instead, it batches iterations or sprints
together into releases.

Those not familiar with the Agile process tend to worry each version of a product becomes a random
collection of features, but a release plan actually ensures that you create a coherent version of your product
every time. It’s a great tool for combining changes that will have a significant impact on the user experience
in a shorter period of time. In fact, implementing Agile can help you cut your time to market for a new
product by up to 70%.

How to implement Agile release planning

The steps below assume that you’re already familiar with Agile principles, and have implemented an Agile
workflow in your company. If that’s the case, getting started with Agile release planning is quite simple.

https://rajadevops.wordpress.com/mca-materials/ Page 26
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
1) Evaluate your product vision and roadmap and single out outcomes

Your overall product vision and the product roadmap should guide the whole process. Focus on outcomes in
terms of which are the most important in the short to medium term and according to stakeholder and
customer demand.

2) Expand and prioritize your product backlog based on these outcomes

If you use Scrum, meet with your Agile team for a product backlog refinement meeting. Break down your
desired outcomes into specific user stories and add them to your backlog.

Prioritize the backlog, based on the desired outcomes, starting with an MVP (minimum viable product). For
Agile frameworks that don’t use a product backlog, like Feature-Driven Development, review the equivalent
item. In the case of FDD, it’s the features list.

3) Set a clear release goal that combines logical product backlog items

Create a release goal that combines different user stories into a meaningful change in user experience. For
example, the ability of a user to access different analytics reports on the mobile app. If you’re creating
multiple reports, it makes sense to release them together, rather than piece-meal.

4) Break your releases down into multiple sprints or iterations

Once you’ve got your release goal and targeted user stories, it’s time to start planning your actual sprints.

Don’t forget the main Scrum values.

o Keep sprints short and commit to an achievable number of user stories.

o Focus on one sprint at a time.
o Have the courage to break the release plan when absolutely necessary.
o Respect everyone’s perspective when choosing items and estimating scope.

The key thing to remember for this step is to not overestimate or try to tackle a huge release in one go while
balancing the need for timely releases — a principle of Agile development. Honing this skill is an art that
improves with practice, so don’t be afraid to adjust your release plan and your sprint planning as you go.
That’s what being Agile is all about.

What Is Risk in an Agile Project?

The Project Management Body of Knowledge which contains the Project Management Institute standards
(source: PMBOK, part 1, ch. 11, p. 397) distinguishes risk into to different types: Individual project risks
that have a positive or negative impact on project goals if they occur, and overall risk that would affect the
project as a whole.

Agile projects often aim to incorporating project goals more intensely than traditional projects. In a daily
Scrum, for instance, team members might answer the question ‘what have I created since the last meeting’
and ‘which impediments am I facing’ with reference to the project goals (or sprint goals, to be precise).

https://rajadevops.wordpress.com/mca-materials/ Page 27
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Teams and team members in waterfall projects might tend to focus on their own areas and deliverables they
are individually responsible for.

While this may smoothen the management of individual risks in agile projects, it does not necessarily so for
the overall project risks. In particular if they are external to the project – e.g. social, technological,
economical, environmental and political risks (STEEP) – an agile project is probably quicker to react to their
occurrence. Yet, it also needs to manage these risks in advance as the flexibility to react might not be
sufficient.

For instance, agile project teams are able to quickly adapt to stricter regulatory requirements for the software
or service they produce. However, the risk exposure to other overall project risks is not necessarily different
from traditional projects – e.g. if this service or product gets prohibited entirely or if their office building
burns down.

Background of Agile Risk Management

Risk Management in agile projects differs from traditional risk management in predictive types of projects.
This is because of the shorter development cycles and the less planning-focused methodology of agile
approaches. Thanks to the improved collaboration between the business and the execution or development
sides and the regular refinement of requirements backlogs, many types of risks are less likely to occur while
the project is able to react quicker to issues and threats.

However, this does not suggest that agile projects are entirely risk-free. It only implies that different
approaches to the management of risks are needed that take the characteristics of these types of projects into
account.

How Risks are Managed in Agile Projects

Most agile frameworks do not contain dedicated risk management processes given as they are focusing on
quality as a built-in element of agile development processes. Tools and techniques such as early feedbacks,
joint business and IT teams, pair programming or testing as a central or even driving part of the development
process aim to increase quality and thus reduce internal risks.

These approaches are quite effective to maintain quality and avoid fatal issues in late stages (as they could
occur in waterfall projects, e.g. if fundamental malfunctions are only detected in the testing phase, almost at
the end of the project).

However, they might not entirely address external risks a project is exposed to. These may include
environmental, political and legal risks (e.g. if elements of the product are subject to regulatory
requirements), for instance. While these risks may be impactful on projects of all different sizes, the risk
exposure becomes even more complex for agile projects of a larger scale, such as Scrum-of-Scrums or
Disciplined Agile.

Although there is no generic or prescriptive approach to risk management in agile projects, it has become a
good practice to leverage on some processes and techniques of traditional project risk management.

With reference to these frameworks, risk management for agile projects consist of the following steps:

 Risk identification,
 Risk assessment,

https://rajadevops.wordpress.com/mca-materials/ Page 28
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
 Risk responses, and
 Risk review.

In predictive projects, this is often done during the project set-up and updated on an ongoing basis during the
entire project lifecycle. In agile projects, these steps are performed at least once for each iteration, and
updated during the development cycle. Regular communication within project teams, such as the daily
stand-up meeting in Scrum, facilitate the quick identification and assessment of risks.

Let’s look at the details of each of these steps:

Risk Identification

This step requires the team, the project manager or an equivalent role and the business side or product owner
to identify potential risks for achieving the project goals.

While this is initially done in meetings, using the typical agile information gathering tools and techniques, it
is also incorporated in the daily project work.

In Scrum, for instance, one of the topics discussed in daily Scrums relates to potential impediments (i.e.
risks) team members are expecting for their respective next step.

Risk Assessment

As in traditional projects, risks are evaluated by the probability of occurrence and the impact they might
cause if they materialize. Projects typically use a matrix to assess the value of these risks which is a basis to
come up with risk responses and prioritization.

Risk Responses

The risk responses are potential or actual strategies to deal with positive and negative types of risk when
they occur. Assigning responses to the most relevant risks is a good practice in both traditional and agile
projects. The project management methodology (PMBOK, part 1, ch. 11.5.2.7, p. 445) defines the following
response strategies for overall project risk:

 Avoid
 Exploit
 Transfer / share
 Mitigate / enhance
 Accept

While project risk management in waterfall projects tend to focus on planning which includes avoidance and
mitigation strategies, agile approaches embrace the learnings and the required changes that may stem from
(small) failure. A good example of a ‘doing rather than planning’ mentality is the quick initial development
of potential solutions to a requirement in order to explore its feasibility. Some frameworks explicitly suggest
the development of these so-called ‘spikes’ to test different options and, thus, reduce risks.

https://rajadevops.wordpress.com/mca-materials/ Page 29
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Risk Review

Risk reviews comprise the check and review of identified risks and issues. A result can be the re-adjustment
of impact and probability assessments or the re-assignment of potential risk responses. Risk reviews are
ideally done on a regular basis, at the least at the start or end of a development cycle.

Tools and Techniques of Agile Risk Management

The tools and techniques used in agile risk management include yet are not limited to:

 Risk Burndown Chart

 Risk Register or Log
 Risk Modified Kanban Board
 Risk Probability and Impact Matrix
 Prioritizing Backlogs based on Value and Risk
 Identifying / Discussing Risks in Regular Meetings (e.g. Daily Scrum)

In practice, there are plenty of tools, techniques and approaches to manage and monitor risks in an agile
project. In fact, every agile project follows a somewhat unique approach in terms of how and to which extent
they decide to deal with risks. This is in line with what agile frameworks given that their aim is not to be
prescriptive methodologies.

Risk Management in Agile Projects (in a Nutshell)

 Short development cycles and quick delivery of increments aims to reduce complexity and risks
 Testing is part of the development cycle and business people are often part of the project or
development team which reduces risks
 High responsiveness to changes
 Most frameworks do not prescribe risk management processes and techniques which requires the
project team to select and adapt adequate measures

Iteration Planning

Iteration planning is needed from the beginning of the scrum process as it helps to manage the software
development more efficiently. The team backlog is partially done during the program increment (PI)
planning. The team and the tasks are matched for the sprint backlog and then iteration planning is done for
one successful sprint.

Let us discuss some of the terminologies in agile and scrum development. The scrum is part of the agile
methodology that is used in software development. The scrum consists of three major parts for software
developments are Product backlog (living artefact), Sprint backlog, and work done status.

The living artefact is planned and is done by the product owner and generally consists of user stories and
epics. A story is the smallest part of the product backlog that can be programmed in the sprint to make a
value in the work done area or the software development. This can be a function or any smallest
requirements of the whether business or technical or functional that can be realized as the outcome in the
form of a feature.

https://rajadevops.wordpress.com/mca-materials/ Page 30
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
An epic is a large part of the requirements that need to be broken down into the smallest part such as user
stories. Learn more to get more knowledge on the SAFe course at the best training institute.

A sprint backlog consists of the group of tasks that is obtained from the user stories of the product backlog
that can be converted into features in a single sprint iteration. The work done consists of multiple features of
the products after several sprint iterations.

A scrum master manages the scrum sprint iterations. A product owner is in charge of the complete project
and is tasked with the responsibilities of making the user stories, and epics from the requirements and then
sequence and schedule the product backlog.

What is iteration planning in agile?

Iteration planning is the process by which planning is done on how many tasks can be lined up to make the
feature in a single sprint. Sometimes a single feature consists of multiple sprint iterations. The owner and the
master based on the resources decide how many tasks can be committed in a single iteration.

Iteration planning is helpful to make the sprint and the product backlog more effective and the development
activities of the tasks more efficient. Planning is the key to success. At every stage one must meticulously
plan to deliver the right outcome. The repetitive process became successful in development due to the right
planning at the right time. The entire team sits together to plan and commit about how much they can
complete.

Before proceeding know the difference between iteration and incremental model.

https://rajadevops.wordpress.com/mca-materials/ Page 31
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
When is iteration Planning completed?

Logically speaking the iteration planning is completed only when the last sprint backlog is committed with
the final sets of tasks. However, each set of sprint backlogs consists of iteration planning and is completed
on the completion of that particular sprint.

1) Inputs to the iteration planning – These are nothing but the tasks that can be accomplished by the team
in the single iteration that is a single sprint. This is planned using the user stories, during the sequencing and
scheduling of the user stories and taking in to account the previous projects or the historical averages, from
lessons learned from previous projects, taking into account any similar projects completed previously and by
studying any other similar team in the other projects. One other important parameter is the system demo that
was done before the start of the project.

2) Planning the iteration – This is done when the product owner establishes the program increments and
then breaks down the requirements into user stories for the resources to work on.

3) Capacity estimation – This is nothing but calculating the time required by the resources such as velocity
and story points calculations. For example – If a sprint is said to be for one week and then there are 4
developers and 3 testers and 1 Product owner then the velocity is calculated as 5 * 8 that is 40 story points
estimation per iteration and so on.

4) Story Analysis and estimation – This is done by the product owner when each user story and epics are
made in the product backlog depending on the complexity, how long it will take to complete, how many
resources are needed, size, difficulty, acceptance criteria, technical challenges, and uncertainty. This is also
called the Behavior-Driven Development (BDD) of the tasks in Scrum.

5) User stories – This is nothing but making the individual tasks from the user's stories for the resources to
act upon and complete the tasks in a sprint backlog and then planning many more iterations if required.

6) Goals of the iteration – Making the iteration goals to develop a feature of the product is the next step.
The iteration goals will accomplish certain customer requirements in an iteration.

7) Finally committing to the iteration goals – Once the goals of the single iteration are established and
worked upon then committing to the iteration goals are the final steps in the iteration planning stages.

What is safe iteration planning?

An iteration planning is done by taking into account resources and the tasks and the resources time usually a
single day and sometimes a week. So a safe iteration planning takes into account all the above things and the
simple logic that a single sprint is completed in a day with necessary resources by taking into account if a
resource is unable to turn up for the work then how the tasks will be completed. There two main metrics that
come into picture are Story points and velocity. The story points are the capacity of the team to complete a
single iteration taking into account the velocity of the team. A story point is a relative story that is 8 point
user story is 4 times the efforts of the 2 point user stories. A velocity is the historical average of all user
stories completed per iteration.

Therefore a safe iteration planning takes into account the velocity of the team and the story points average
they can realize in a single iteration.

https://rajadevops.wordpress.com/mca-materials/ Page 32
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
What are stories, epics, and initiatives?

 Stories, also called “user stories,” are short requirements or requests written from the perspective of an end
user.
 Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
 Initiatives are collections of epics that drive toward a common goal.

Agile epic vs. story

In a sense, stories and epics in agile are similar to stories and epics in film or literature. A story is one simple
narrative; a series of related and interdependent stories makes up an epic. The same is true for your work
management, where the completion of related stories leads to the completion of an epic. The stories tell the
arc of the work completed while the epic shares a high-level view of the unifying objective.

On an agile team, stories are something the team can commit to finish within a one- or two-week sprint.
Oftentimes, developers would work on dozens of stories a month. Epics, in contrast, are few in number and
take longer to complete. Teams often have two or three epics they work to complete each quarter.

If your company was launching rockets into space, and wanted to improve the streaming service for your
launches, you might structure your stories like the ones below.

Examples of an agile story:

 iPhone users need access to a vertical view of the live feed when using the mobile app.
 Desktop users need a “view fullscreen” button in the lower right hand corner of the video player.
 Android users need to be linked to apple store.

The above stories are all related, and could all be considered individual tasks that drive toward the
completion of a larger body of work (an epic). In this case, the epic might be “Improve Streaming Service
for Q1 Launch.”

Organizing work into stories and epics also helps you and your team communicate effectively within the
organization. If you were reporting your team’s progress to the Head of Engineering, you’d be speaking in
epics. If you were talking to a colleague on your development team, you’d speak at the story level.

https://rajadevops.wordpress.com/mca-materials/ Page 33
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Agile epic vs. initiative

In the same way that epics are made up of stories, initiatives are made up of epics. Initiatives offer another
level of organization above epics. In many cases, an initiative compiles epics from multiple teams to achieve
a much broader, bigger goal than any of the epics themselves. While an epic is something you might
complete in a month or a quarter, initiatives are often completed in multiple quarters to a year.

Example of epics in an initiative:

Let’s say your rocket ship company wants to decrease the cost per launch by 5% this year. That’s a great fit
for an initiative, as no single epic could likely achieve that big of a goal. Within that initiative, there would
be epics such as, “Decrease launch-phase fuel consumption by 1%,” “Increase launches per quarter from 3
to 4,” and “Turn all thermostats down from 71 to 69 degrees #Dadmode.”

At Atlassian:

Internally, we call our initiatives “PC Tickets.” Project Central tickets are configured in Jira Software just
like our epics. Each team takes their four or five most important goals for the year and makes PC tickets for
each one. These PC tickets are used by the founders and management to understand all the work being done
in the company.

Beyond initiatives

In many organizations, the founders or leadership team encourage the pursuit of some aspirational
destination. These are the (sometimes super corny) goals announced each year or quarter. Initiatives are
typically collections of epics, but you can also use custom fields or labels to categorize by team, strategic
pillar, or timeframe, and create a custom hierarchy to better align work to higher-level organizational goals.

Many Atlassian customers leverage Advanced Roadmaps in Jira Software to introduce five levels
above agile epics to define and guide projects, which are shown below.

https://rajadevops.wordpress.com/mca-materials/ Page 34
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

User Stories in Agile Software Development

In Agile software development and product management User Story refers to a short, informal, and simple
description of software features that are required by the end-users in the software system. Its main purpose
is to provide software features that will add value to the customer requirements. User stories are
considered an important tool in Incremental software development. Mainly a user story defines the type of
user, their need, and why they need that. So in simple, a user story is a simple description of requirements
that needs to be implemented in the software system.

Pattern of User Story :

User stories are completely from the end-user perspective which follows the Role-Feature-Benefit pattern.

As a [ type of user ], I want [ an action ], so that [ some reason ]

For example :
As the project manager of a construction team, I want our team-messaging app to include file sharing and
information update so that my team can collaborate and communicate with each other in real-time as a
result the construction project development and completion will be fast.

Writing User Stories :

User stories are from a user perspective. So when user stories are written, users are given mor e importance
during the process. Some points outlined which are taken into consideration during writing user stories
like

https://rajadevops.wordpress.com/mca-materials/ Page 35
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
1. Requirements
2. Tasks and their subtasks
3. Actual user
4. Importance to user words/feedback
5. Breaking user stories for larger requirements

With this also some other principles which are given importance during creating user stories are discussed
below.

INVEST Principle of User story :

A good user story should be based on INVEST principle which expresses the quality of the user story
because in base a good software product is completely dependent upon a good user story. In 2003
INVEST checklist was introduced by Bill Wake in an article.

1. Independent –
Not dependent on other.
2. Negotiable –
Includes the important avoid contract.
3. Valuable –
Provide value to customer.
4. Estimable –
It should be estimated.
5. Small –
It should be simple and small not complex.
6. Testable –
It should be evaluated by pre-written acceptance criteria.

3 C’s in User Stories :

1. Card –
Write stories on cards, prioritize, estimate and schedule it accordingly.
2. Conversation –
Conduct conversations, Specify the requirements and bring clarity.
3. Confirmation –
Meet the acceptance criteria of the software.

Working with User Stories :

Below points represents working with user stories

1. Once the user story is fully written then it undergoes review and verification.
2. In project workflow meetings it is reviewed and verified then added to the actual workflow.
3. Actual requirements and functionality are decided based on the stories.
4. User stories are scored based on their complexity and the team starts work based on user stories.

Importance of creating User stories :

https://rajadevops.wordpress.com/mca-materials/ Page 36
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
1. Stories clear idea about requirements
2. Makes it easy to understand the features
3. Delivers higher customer satisfaction
4. Fasten development process
5. Creates an effective work environment
6. Enables collaboration between teams
7. Delivery of valuable software

What is Estimation in Agile?

Agile estimation is the process for estimating the effort required to complete a prioritized task in the product
backlog. This effort is usually measured with respect to the time it will take to complete that task, which, in
turn, leads to accurate sprint planning.

What is a Sprint? A sprint is a time-boxed interval that defines the time allocated to complete a task.

Note: No matter how accurately a business estimates the effort required to complete a user story in Agile, an
estimate is still an estimate. Do not strive to achieve perfect accuracy because requirements can change at
any time. There are also agile anti-patterns and other emerging realities that change the course of
development.

Agile teams also make estimations with reference to story points. A story point is used in Agile
Development projects to estimate the difficulty of implementing a given user story. This is measured in
relative units assigned to different user stories that require estimation.

In a nutshell, a story point is a number that helps estimate the difficulty of building a user story successfully.
This difficulty could be anything related to the complexities, risks, and efforts involved.

Agile project estimation also helps to build strong coordination. If project X is dependent on project Y, agile
project estimation provides an overview of the wait time.

Why Run Agile Estimations?

Agile estimations are essential for:

 Making teams accountable for deliverables

 Inducing discipline across the Agile team
 Predicting the approximate time it will take to finish a project
 Enabling better sprint management
 Improving team productivity

Why do Teams Estimate in Agile?

Overestimating and underestimating are both common for Agile development teams which leads to varying
development and launch times. Though the process is complicated, considering Agile estimation in the
initial stages can assist with accurate user story estimations and helps the team stick to the timely
deliverables.
https://rajadevops.wordpress.com/mca-materials/ Page 37
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
Some of the to-the-point benefits of Agile Estimation techniques include:

1. Improved Decision-Making

With accurate, agile estimation, the development team will be able to conduct effective backlog grooming
sessions, which will further help in precise sprint planning. When they make informed decisions and plan
well, their user story delivery time will improve.

2. Better Coordination

Let’s say that the estimated effort for user story A is two weeks. On the other hand, the estimation effort for
user story B is four weeks. Now, suppose both the user stories depend on each other and are connected. In
that case, the team needs to prioritize work so that both user stories get completed simultaneously, thus
leading to better coordination among teams.

3. Better Risk Management

Software projects often suffer from exceeding budgets and timelines. To lessen this risk, Agile project
estimation is an ideal solution. Agile product estimation helps estimate story points and stick to budgets,
estimates, and the project’s scope. The more accurate the estimates, the better the chances of on-time,
quality delivery.

Stages of Agile Estimation: The Short Discovery Phase

When a project starts, the horizon is limited. Thus, it is wise to implement a short product discovery phase to
tide over this problem. The discovery phase establishes the essential tenet of Agile methodology, which
consists of breaking down the requirements into small batch sizes.

https://rajadevops.wordpress.com/mca-materials/ Page 38
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21

This is an exercise that typically takes two to four weeks, depending upon the project’s complexity.

The in-detail process includes:

1. Conduct Stakeholder Interviews

The Business Analyst (BA) assigned to the discovery team revisits any existing documentation shared
initially and extracts the gaps and queries. The BA then conducts regular workshops with the stakeholders to
discuss the gaps and clarify doubts in the system workflow.

Based on these workshops, the BA comes up with the business and functional requirements:

 Business Requirements Document (BRD): defines the end-goal of the project

 Functional Requirements Document (FRD): defines the features required to achieve the end-goal

These workshops can be conducted over a call with the client or when they visit the premises to have one-
on-one sessions.

2. Define High-Level Product Backlog

The next step of Agile Estimation involves the BA and the Technical Architect. They frame an initial
outcome that the stakeholders are looking for with a feasible solution or product.

https://rajadevops.wordpress.com/mca-materials/ Page 39
 DEVOPS & AGILE PROGRAMMING Unit-2 R20 & R21
A high-level product backlog is defined in terms of epics and story titles, which describe the bare bones of
the application. They then validate if the backlog addresses the scope of the project for the client.

3. Understand the Client and its Potential Customers

Depending upon the complexity of the problem that the application is intended to solve, a UX design anchor
is taken on board along with the BA for the discovery phase. The UX analyst’s prime deliverable is to
understand not just the client but also their potential customers.

The UX analyst works on personas of the possible user group who might use the application, the ecosystem
in which the personas will be using it, and the touchpoints of the user personas within the system. The
deliverables here would be ecosystem maps, personas, user journeys, and storyboards.

4. Prioritize Requirements

The discovery team becomes involved in the agile cost estimation project and works on the high-level
backlog after it has been validated by the stakeholder.

The analysis is employed with the prioritization method to decide which requirements to complete first,
which ones can come later, and which ones to exclude. The backlog items are divided on the basis of the
MoSCoW method, which segments features based on must-haves, should-haves, could-haves & won’t-
haves.

5. Prepare the Minimum Viable Product (MVP) Backlog

Based on the prioritization activity, the BA assembles the requirements as ‘must-haves’ to the backlog and
sections them as the requirements for the MVP Development.

The MVP backlog might also contain a few items from the ‘should haves’ list, ensuring that the product is
sufficiently competitive in the market.

P.S.: In some instances, depending on the budget and time to market, this step is skipped, and the agile
teams jump directly to developing the fully-fledged product.

6. Estimate the Project Cost and Timeline

The discovery team estimates the MVP backlog to define the estimated cost and timeline for the first release.

This is followed by build, rinse, and repeat until they arrive at an estimate that fits the business needs. This
also allows flexibility to load and off-load features as product development starts.

https://rajadevops.wordpress.com/mca-materials/ Page 40