Devops & Agile Programming Unit-2

DEPARTMENT O
OF MCA
A STUDY MATERIAL OF
Dev ops & Agile Programming

JNTUA R21 REGULATIONS
Unit-2
FOR
MCA 2 YEAR - I SEM
Prepared by
Mr. B. VENKATA REDDY

Asst. Professor Dept. of MCA
II MCA III Sem - Dev Ops & Agile Programming by B.Venkata Reddy Unit-2
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.
1. 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.
2. 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.
3. Software Build: The development

team works on building the software
based on user stories and acceptance
criteria.
4. 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.
5. 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.
6. 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.
7. 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.
ALTS |Department of MCA Page 2 of 40

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 the 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.
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 continuously with no human
involvement in the release process.

These three practices together are called continuous software

development and are associated with agile methodologies and Dev Ops. 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 check list 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.
 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 down
time, 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 work around 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
work around 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 time box 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 time box 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 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 miss functioning of the product.
Functionalities that aren’t present in the product, they must be handling 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 un estimated 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 in to the code, debug,
and 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. Anytime 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, and 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 bench marks.

 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?

Version control is defined as a system that tracks the progress of code across
the software development lifecycle and its multiple iterations – which maintains a
record of every change complete with authorship, timestamp, and other details – and
also aids in managing change.

II MCA III Sem - Dev Ops & Agile P
Programming by B.Venkata Reddy Unit-2
The process of monitoring and managing changes to software code is known as

version control, also sometimes referred to as revision control or source control
systems. Software technologies
echnologies called version control systems assist software
development teams in tracking changes to source code over time.
Version control systems enable software teams to operate more swiftly and
intelligently as development environments have increased. They are beneficial for
DevOps teams because they will allow them to speed up successful deployments and
reduce development time.
Version control, also known as source control, is the practice of tracking and
managing changes to software code. Version cont
control
rol 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
carefuleffort.Versioncontrolprotectssourcecodefrombothcatastropheandthecasualdeg
trolprotectssourcecodefrombothcatastropheandthecasualdeg
radationofhumanerrorand 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.
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.Beingabletotraceeachchangemadetothesoftwareandconnectittopro
jectmanagementand 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.
Types of Version Control Systems:

The types of VCS are:
1. Local Version Control System

2. Centralized Version Control System
3. Distributed Version Control System
1. Local Version Control System:
A local version control system is a database located on your computer that

stores every file change as a patch. A patch set contains only the changes made to
the file since its last version. To see what the file looked like at any given moment,
you need to add all relevant patches to the file until that moment.

Local Version Control System
The main issue here is that everything is saved locally. If anything were to
happen to the local database, all patches would be lost. Similarly, if any damage
occurred to a single version, all changes made after that particular version would no
longer exist.
While it can be difficult to collaborate with other developers or teams, there are
ways to make it work.
Local Version Control System Example

2. Centralized Version Control Systems
A centralized version control system is ideal for teams who need to work on the
same project at the same time. Multiple clients can access files simultaneously with
a single server containing all file versions. This way, everyone usually knows what
everyone else is doing, and administrators have control over who can do what.
This makes it easy to collaborate with other developers or a team.

The biggest issue with th this

is structure is that everything is stored on a
centralized server. However, if something were to happen to that server, people could
still access their versioned changes, pull files, and collaborate. Similar to Local
Version Control, If the central databas
databasee were to become corrupted, you would lose
the entire history of the project except for whatever snapshots people have on their
local machines. It is, therefore important to keep backups in order to avoid losing
data.
Two well-known
known examples of centralized version control systems are Microsoft
Team Foundation Server (TFS) and SVN.
Centralized Version Control System Example
3. Distributed Version Control Systems
If you’re using a distributed version control system, you don’t just check out
the latest snapshot of files from the server. You also mirror the repository, which
means that everyone collaborating on a project has their own complete history of the
project stored locally.
Distributed Version Control System

If the server becomes unavailable or dies, no worries! 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. We just need one client with a correct copy,
which can be distributed easily.
Git is a prime example of a distributed version control system.
Distributed Version Control System Example
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 matter it allows the team to “fail fast”.
Fast Feedback
Agile/Scrum emphasizes 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 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 s story can be put in front of the product owner
o and
stakeholders within minutes, feedback, acceptance, or rejection, can be given to the
team in near real time. Agile/
Agile/scrum moves pretty fast, but our 10 Minute Build
means that when sprint review rolls around our s stories
tories have a higher acceptance
rate. Fast feedback
eedback 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 minimize the amount of

in progress user stories in our ssprints.
ts. Team members can often get fast feedback
f
before
e they get too deep into other user s
stories.
Any scrum master 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 Cycle
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
pted (not uncommon!). With cycle we invested time and effort upfront in
engineering to give us:

 Continuous Integration (we use Jenkins)

 Automated Build (a synchronous on an AWS instance)
 Automated Deployment (we use Octopus)
Here’s our current process:
 A developer merges code to our development branch on Git hub

 A web hook 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 Dev Ops 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 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
driven development. This is done by
running and passing all unit tests in the developer's local
ocal environment before
committing to the main line. 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 co

commit
and reports the results to the developers. The use of build servers had been
introduced outside the XP (extreme programming) community and many
organizations have adopted CI without adopting all of XP.
Run tests in CI
In addition to automated unit tests, organizations 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 tional 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,
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 ide
ideaa 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 main line 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 with in 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 the 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,

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.
 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 team collectively.
 Efficient and Useful Code Reviews
When no one else other than one person knows about the code with in 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 within the development team.
It is continuous learning that keeps 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 every one’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.
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 de motivate 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.

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 life cycle 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.
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
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 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 5levels of planning for such large scale
development
1. Product Vision
Before creating your vision statement, we must focus on the customer by

identifying the roles that will be interacting with the product. This step will help
better understand the customer and will help in writing user stories based on these
roles. Another technique to consider at this stage is to associate personals for each
role. These personals will help the team humanize the work and ensure that they
write test scripts for different types of users that go beyond the obvious user
experience.
The Vision provides a top-level view of the ultimate objective for the
business. It is strategic and transcends any one project. The Vision provides a
way with which to judge related actions through a simple question. “How does
this forward the Vision?” Visions are best when they are exciting, inspirational,
attainable, and aggressive. The scope of a Vision is usually measured in years.
2. Roadmap
Roadmap is a plan on how the product should evolve to achieve the above
vision. The 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.

The Roadmap is a collection of key deliverables for achieving the Vision.

Each deliverable is documented as an “epic” (a large, coarse-grained story), from
the perspective of the “customer” (where customer is defined as whomever will
use and benefit from the deliverable). The scope of a Roadmap is nominally 18
months.
3. Release Plan
The Release Plan defines the list of features that will be delivered in the
decided timeline. A Release plan is a collection of the most important (valuable)
Roadmap stories that can be delivered in a reasonably short time – short enough
that business focus is unlikely to change during the Release time frame
(nominally three months). The collection of stories is prioritized so if the
schedule slips, the most valuable stories are still completed and delivered.
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?
 What potential impediments are there to my progress?
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.
The purpose of the Daily meeting is to align and coordinate the work of the
team, as well as encourage accountability for progress.
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].
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?
 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

 Customer feedback – 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/ Vision – 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
 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.

Figure 3. The Roadmap is part of the vision

PI Planning Vision—the
the Top 10 Features
The roadmap ap 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 step
steps
s forward, one PI at a time and one
feature at a time, as Figure 4 illustrates.
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 tea
team.
m. 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
well-formed
formed and vetted. Architect/Engineering has
already reviewed them, and various Enablers have already been implemented.
Figure 4. Vision is achieved one PI at a time, via the “Top 10 Features for the next PI”

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.

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.
 Keep sprints short and commit to an achievable number of user stories.

 Focus on one sprint at a time.
 Have the courage to break the release plan when absolutely necessary.
 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).

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

consists of the following steps:

 Risk identification,
 Risk assessment,
 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, facilitates 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, part1, 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 learning’s 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 frame works explicitly suggest the development of these so-
called ‘spikes’ to test different options and, thus, reduce risks.
 Risk Review
Risk reviews comprise the check and review of identified risks and issues. A
result can be there-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 Burn down Chart

 Risk Register or Log
 Risk Modified Kanban Board
 Risk Probability and Impact Matrix
 Prioritizing Backlogs based on Value and Risk
 Identifying/Discussing Risk sin 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 Nuts hell)
 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 frame works 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 artifact), Sprint backlog, and work done status.
The living artifact 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.
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 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.
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. A goal 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 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 point’s average they can realize in a single iteration.
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. Often times, 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:
 I Phone users need access to a vertical view of the live feed when using the
mobile app.
 Desktop users need a “view full screen” 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
communicates effectively within the organization. If you were reporting your team’s
progress to the Head of Engineering
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.
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
launch-phase
phase fuel consumption by 1%,” “Increase
launches per quarter from 3 to 4,” and “Turn all thermostats down from 71 to
69 degrees #Dad
ad mode.”

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
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 time
frame, 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.
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
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 off 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 more importance during the process. Some points
outlined which are taken into consideration during writing user stories like
1. Requirements
2. Tasks and their sub tasks
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.

3C’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 work flow meetings it is reviewed and verified then added to the
actual work flow.
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:
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

completing 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?
Over estimating 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.
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.
This is an exercise that typically takes two to four weeks, depending upon the
project’s complexity. The in-detail process includes:
1. Conduct Stake holder 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.

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 person as of the possible user group who might
use the application, the eco system in which the personas will be using it, and
the touch points 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 back log 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.

Devops & Agile Programming Unit-2

Uploaded by

Devops & Agile Programming Unit-2

Uploaded by

DEPARTMENT O

Dev ops & Agile Programming

MCA 2 YEAR - I SEM

Mr. B. VENKATA REDDY

Why do you need Release Management?

Multiple delivery teams often work in parallel in an organization, which can

The release management process

Release Management, like software development, progresses in cycles. Whether

2. Release Planning: All the

3. Software Build: The development

4. Review: The new software code is

5. Deployment: Sometimes a feature is deployed incrementally—first to internal

7. Feedback collection: Customers who reach out with questions or feedback

ALTS |Department of MCA Page 2 of 40

Release Management in Agile

The practice of continuous integration advises developers to merge their

While continuous integration places emphasis on automated testing,

With continuous deployment, the entire process is automated, including

The three practices of Continuous Software Development

ALTS |Department of MCA Page 3 of 40

These three practices together are called continuous software

Role of a Release Manager

Release management best practices

Ensure your backlog is prioritized at all times. This eliminates any

 Create a release checklist

An exhaustive check list of things to double-check before a release can

 Triage your feedback

 Identify metrics for observation

To understand the impact of a release, it's important to identify relevant

What is a Bug in Agile?

ALTS |Department of MCA Page 4 of 40

Agile Bugs classification

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

2. Medium priority bug — there is a work around available. For example, I

Do we add user stories to the Bugs in Agile?

Scenario 1: Assign the time box to the bugs.

Scenario 2: Refine the bugs and estimate them in user stories.

ALTS |Department of MCA Page 5 of 40

Counting bugs in Scrum team velocity

By default, velocity means progress, new functionalities that are being

How do we deal with urgent bugs in Agile?

How to minimize the Agile bugs in your product?

 Increase the code quality respecting the industry bench marks.

What is version control?

ALTS |Department of MCA Page 6 of 40

The process of monitoring and managing changes to software code is known as

Version control software keeps track of every modification to the code in a

ALTS |Department of MCA Page 7 of 40

Good version control software supports a developer's preferred workflow

Version control software is an essential part of the every-day of the modern

Benefits of version control systems

ALTS |Department of MCA Page 8 of 40

1. A complete long-term change history of every file. This means every

2. Branching and merging. Having team members’ work concurrently is a no-

While it is possible to develop software without using any version control,

Types of Version Control Systems:

1. Local Version Control System

1. Local Version Control System:

A local version control system is a database located on your computer that

ALTS |Department of MCA Page 9 of 40

Local Version Control System

Local Version Control System Example

This makes it easy to collaborate with other developers or a team.

ALTS |Department of MCA Page 10 of 40

The biggest issue with th this

Centralized Version Control System Example

3. Distributed Version Control Systems

Distributed Version Control System

ALTS |Department of MCA Page 11 of 40

If the server becomes unavailable or dies, no worries! Any of the client

Git is a prime example of a distributed version control system.

Distributed Version Control System Example

10 Minute Build For Agile/ Scrum

Agile/Scrum emphasizes the importance of feedback loops, for example our

Another consequence of our 10 Minute Build is that we minimize the amount of

Building in quality from the beginning: