Assignment on Agile Best Practices

Q.1. Difference between 3 types of meetings?

Sprint Planning Meeting Stand-Up Meeting Sprint Review Meeting

 It is held for 2-4 hours  It is held for 15  It is held for 2-4 Hours
for a 1-Week Sprint minutes, Every Day

 This is a first Sprint  This meeting should  This meeting is held

meeting which should be held every day, at at the very end of the
be held at the very the same time, Sprint. In many cases,
beginning of and same place. you will hear people
the Sprint using the term “Sprint
Demo," as this is
actually what this
meeting is about.

 In the meeting the  In the meeting, all  In the meeting the

whole team is present, team members product owner,
including the Product should be present, the Scrum team, the
Owner and the Scrum including the Scrum Scrum Master,
Master.
Master.  management,
customers and
developers 

 In this meeting, the  In this meeting, the  In this meeting the

team will take the top whole team will be team should present
items from the able to only the working
backlog and estimate have visibility into items that they have
or forecast how much where exactly they delivered to met
they will deliver in the are in delivering on the Definition of Done
Sprint and based on the Sprint goal and if (DoD), which means
that they will gauge everything is going in that this item doesn't
the team's velocity. the direction to be require any more
delivered on time. work to complete it.
It's ready to be
delivered.
 Goals of the meeting Goals of the meeting Goals of the meeting

 Agreed and verified  What they did  Explain what items

about the PBIs that yesterday that can have been "Done"
will be delivered in help the team to and what has not
the Sprint. successfully deliver been "Done."
 Add all the team items from the Sprint  Discuss what went
members' capacity, Planning. well during the Sprint,
days off.  What they are going what problems the
 Assigned the User to do today that will team ran into, and
Stories to team help the team to how those problems
members. finish the Sprint. were solved.
 Are there any  Demonstration of the
blocking points or functionality built
impediments in their during the Sprint.
way?

Q.2. Elaborate each of the Best Practices more and write 1-page each for these 17 Best
Practices. (Maximum 12 font size)

1. Iteration

In agile software development, an iteration is a single development cycle, usually measured

as one week or two weeks. An iteration may also be defined as the elapsed time between
iteration planning sessions. An Agile iteration is a short one to two week period where a
team takes a couple of their customers most important user stories and builds them
completely as running-tested-software.

Scrum and XP Iterations

 Scrum is an agile methodology that is defined by iterations. In Scrum, iterations are
called sprints and are typically two weeks long. Each sprint is bookmarked by formal
meetings, with project work being taken on at the beginning and completed and ready
for review at the end. The sprint is advanced by daily meetings where the progress of
the work is discussed.
 Extreme Programming (or XP) is another agile methodology that uses iterations. Like
Scrum, the iterations typically last around two weeks. Unlike Scrum, XP is not defined by
iterations. They provide the time frame for project work to be completed, but the
 primary focus is on how the work is completed. XP gives a framework for how to
develop and test project work, which is the defining characteristic of the methodology.
The Agile team implements the PDCA cycle on each iteration separately in the following
manner:

 P (Plan) – Iteration Planning

 In this event, the team collaborates to discuss the objectives for the next iteration. It also
summarizes the work done and determines the team backlog required for the next
iteration.

 D (Design) – Iteration Execution

 This is the ‘do’ step where the development of the software, its design and coding takes
place. If it’s a second or third iteration, then functionality testing is also conducted. The
team collects user stories and prepares for the next step that is the Iteration Review.

 C (Check) – Iteration Review

 Also known as the ‘check’ step, Iteration Review is carried out with the Product Owner. The
team shows the tested deliverable to the Product Owner, who then reviews the completed
work and ascertains whether all criteria have been met.

 A (Adjust) – Iteration Retrospect

 In this event, the team evaluates the entire process of the iteration from the first step. It
essentially works on any improvements that are gathered in previous iterations. New
problems are identified along with their causes. Before the team starts the next cycle again,
team backlog is refined for future reference.

2. Customer oriented Approach

The importance of the customer to agile software development teams operating within large
and to the organization as a whole is well documented. The construct “customer focus” has
been developed by the Total Quality Management (TQM) literature. It developed and validated
a customer focus construct in the context of manufacturing firms. They found that quality is
influenced by top management’s commitment through customer focus. Customer focus
practices involve the establishment of links between customer needs and satisfaction and
internal processes.
Customer collaboration is a crucial point in agile methodology. According to the approach, agile
team should provide all the info needed to the clients and inform them of the progress.
Constant communication should be also a part of internal teamwork.
The essence of agile approach for customer can be briefly stated as follows:

 Development is carried out by short cycles (iterations) in 1-4 weeks;

 Customer gets a valuable software (or part thereof) at the end of each iteration, which
can be used in business.

3. Product Backlog

A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure
changes or other activities that a team may deliver in order to achieve a specific outcome.
The product backlog is the single authoritative source for things that a team works on. That means
that nothing gets done that isn’t on the product backlog.
Product backlog items take a variety of formats, with user stories being the most common. The
team using the product backlog determines the format they chose to use and look to the backlog
items as reminders of the aspects of a solution they may work on. Product backlog items vary in size
and extent of detail based in large part in how soon a team will work on them. Those that a team
will work on soon should be small in size and contain sufficient detail for the team to start work.
The team may establish a definition of ready to indicate their agreement on the information they’d
like to have available in order to start working on a product backlog item. Product backlog items
that are not slated for work may be fairly broad and have little detail.

The agile product backlog in Scrum is a prioritized features list, containing short descriptions of
all functionality desired in the product. When applying Scrum, it's not necessary to start a
project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team
and its product owner begin by writing down everything they can think of for agile backlog
prioritization. This agile product backlog is almost always more than enough for a first sprint.
The Scrum product backlog is then allowed to grow and change as more is learned about the
product and its customers.

A typical Scrum backlog comprises the following different types of items:

1. Features
2. Bugs
3. Technical work
4. Knowledge acquisition

Benefits of Product Backlog

 Product backlog items act as placeholders for future conversation about an option for achieving
your desired outcome. That means a team doesn’t have to have an idea fully fleshed out before
adding it to the product backlog. When a product backlog item is initially added to a product
backlog it only needs to have enough information to remind the team what the option was. A
product backlog item only needs to be fully described when a team is about to start work on it.

Common Pitfalls
The product backlog should not be confused with a requirements document. While it serves as an
entry point to requirements information about the product it has some distinct differences from
requirements documents:

 Product backlog items are necessary but not sufficient to describe the intended changes to
the product. A complete understanding of the product comes from conversations that occur about
the individual product backlog items and supplementary information that a team chooses to record
about the product backlog item.
 In contrast to something that appears in a requirements document, the inclusion of a
product backlog item in a product backlog does not guarantee that it will be delivered.
 In contrast to a requirements document which is baselined and is expected not to change
after a certain point, the product backlog evolves as understanding of the product evolves.

4. User Stories

A user story is a small, self-contained unit of development work designed to accomplish a

specific goal within a product. A user story is usually written from the user’s perspective and
follows the format: “As [a user persona], I want [to perform this action] so that [I can
accomplish this goal].”

In agile software development, a user story is a brief, plain-language explanation of a feature or

functionality written from a user’s point of view. Many agile experts also describe a user story
as the smallest unit of product development work that can lead to a complete element of user
functionality. Product teams choose to break development work into user stories instead of
product features or product requirements for several reasons.

User stories:

 Are easy for anyone to understand

 Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
 Help the team focus on real people, rather than abstract features
  Build momentum by giving development teams a feeling of progress

User story examples

In practice, user stories might look like these:

 As a database administrator, I want to automatically merge datasets from different

sources so that I can more easily create reports for my internal customers.
 As a brand manager, I want to get alerts whenever a reseller advertises our products
below agreed-upon prices so that I can quickly take action to protect our brand.

Who should write user stories?

In many agile organizations, the product owner takes primary responsibility for writing user
stories and organizing them on the product backlog. In reality, though, this is a shared
responsibility among the entire cross-functional product team.

5. AGILE ROLES

The Agile methodology involves different roles with different names. An Agile team working in
Scrum has three roles:

 The Product Owner – Often an executive or key stakeholder, the Product Owner has a
vision for the end product and a sense of how it will fit into the company’s long-term
goals. This person will need to direct communication efforts, alerting the team to major
developments and stepping in to course-correct and implement high-level changes as
necessary.

 The Scrum Master – The Scrum Master is most akin to a project manager. They are
guardians of process, givers of feedback, and mentors to junior team members. They
oversee day-to-day functions, maintain the Scrum board, check in with team members,
and make sure tasks are being completed on target.

 The Team Member – Team members are the makers: front- and back-end engineers,
copywriters, designers, videographers, you name it. Team members have varied roles and
skills but all are responsible for getting stuff done on time and in excellent quality.
  Stakeholders
A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager,
operations staff member, the "gold owner" who funds the project, support (help desk) staff
member, auditors, your program/portfolio manager, developers working on other systems that
integrate or interact with the one under development, or maintenance professionals potentially
affected by the development and/or deployment of a software project.

6. Value Stream Analysis

 A value stream analysis is a series of steps that occur to provide the product or service that
their customers want or need. In order to provide the product or service that the customers
desire, every company has a set of steps that are required. Value stream mapping enables us to
better understand what these steps are, where the value is added, where it’s not, and more
importantly, how to improve upon the collective process. Value stream analysis provides us
with a structured visualization of the key steps and corresponding data needed to understand
and intelligently make improvements that optimize the entire process, not just one section at
the expense of another.

This methodology introduces us to two principles.

 The first one is about defining the product based on user stories, which are based on
analysis of the business.
 The second one is about defining dependencies between the business and technical
functionality.

Value Stream Mapping – Stages

Value Stream Mapping progresses in the following stages:
Step 1:  Start by identifying the product or service to be analyzed and the value being created
by this process.
Step 2: Create a value stream map of the current process by identifying the steps, queues,
delays, and information flows.
Step 3: Review the map to find delays, waste, and constraints. This can be done by reviewing
the process and identifying activities that can be classified as waste. Also, identify the
constraints if any.
Step 4: Create a new value stream map of the optimized state to be achieved in the future, by
removing delays, waste, and constraints.
Step 5: Develop a roadmap to achieve the future state.
Step 6: Plan to revisit the process in the future to continually calibrate and optimize.

Value Stream Mapping-Steps

The steps involved in the value stream mapping process are as follows:
  Identify the start and end point of the process
 Identify high-level steps, inventories, and queues
 Identify support groups and alternative flows
 Classify activities as value adding and non-value adding
 Eliminate or minimize the non-value adding steps and optimize the process

7. Timeboxing

Timeboxing refers to the act of putting strict time boundaries around an action or activity. For
example, you may want to time box a meeting to be 30 minutes long to help ensure that the
meeting will begin and end on time with no exceptions. When we time-box an event the result
is a natural tendency to focus on the most important “stuff” first. If you time box a meeting, you
would expect then that the absolutely required content of the meeting be completed before
the end of the meeting. Other meeting agenda items that are not as important may get moved
to another meeting. In essence, time boxing is a constraint used by teams to help focus on
value.

One important time-box that Agile promotes is the project itself. Contrary to Agile mythology,
agile teams prefer to have a time-boxed project since it offers a fixed schedule and a fixed team
size. With these project constraints the team can better work with customers to maintain a
laser focus on value, which ensures the team is building and delivering the most valuable work
as soon as possible—leaving the less critical tasks to the end. Time-boxed projects may mean
that some requirements won’t get implemented. However, it will help to ensure that what is
developed is truly the most essential of the required features.

Timeboxing also helps to prevent a common problem in software development called “feature
creep,” where teams incrementally add features to software without scrutinizing relevance or
need. Feature creep leads to wasted effort in both the development and maintenance of code
and can significantly impact quality and timelines on a project. Time-boxed project teams work
to minimize the effort and resources needed to achieve the expected value. 

Benefits of time-box in Agile and Scrum

There are several major benefits:

 Prioritization
Timebox project management forces you to focus on the task at hand. And since you have a
limited time, tasks are easily prioritized.

 Focus
When deadlines are soft, distractions creep in. But when using a set timeframe, you increase
productivity by focusing on meeting the end goal before time expires.
  Resources

Project management is all about maximizing the time and resources spent on a project. When
you’re using time-boxing in Agile, it’s easy to judge how much each team member is spending
on a project to meet the overall goals.

 Accountability
Every team member needs to pull their weight on a project, but without task timeframes or
sprints, it’s hard to tell when and where a project is falling behind. With time-boxing in Agile,
after each sprint an analysis can be performed showing where deliverables needed stand.

 Patterns
After a project is complete, you can go through your time-boxing sessions and notice patterns.
For example, if you notice projects stall using a certain software program or a certain team
member, you can make adjustments on future projects or invest in the resources your team
needs to make work happen most efficiently.

 Manageable
When you have a large and complex project it can seem overwhelming to a team. But if you
break that project up into small sprints and use time-boxing in Agile, it seems manageable and
you’ll receive better buy-in from everyone involved.

8. Scrum Meeting

Scrum is an agile framework that manages your project and delivers value iteratively at short
intervals. In recent years, it is the most famous methodology used for managing a software
development project. Responsibility of Scrum team is defined in a way that team is self-driven
and target oriented, hence more chances to succeed. This event is a daily short morning
meeting, arranged usually by a product manager or a product owner. It lasts 10-15 minutes.

Agile ceremonies are different practices carried out by teams that are implementing Agile. The
essential scrum meetings are Sprint Planning, Daily Stand-up (daily scrum), Sprint Review and
Retrospective. Teams additionally may need backlog refinement sessions where product
manager makes sure quality of user stories and prioritizes the features list.

1. Sprint Planning
An agile ceremony held by the Development team, Scrum Master, and Product Owner. It is held
at the beginning of a new sprint, with the purpose of setting up prioritized worklist and aligning
the entire team for success throughout the sprint. The Product Owner will discuss a prioritized
backlog with the development team, and the whole group collectively comes up with the
amount of effort involved. The team then decides how much of the work from the backlog can
be completed in this iteration. By following the Best Sprint planning practices, sprint session
span can be kept within 4-6 hours.

2. Daily Scrum or Stand-up

An essential sync up meeting in both Scrum and Kanban methodologies. It is an agile ceremony
held for the Development Team facilitated by the Scrum Master. The Product Owner and the
stakeholders can participate in this meeting to answer the questions raised by the development
team. This meeting takes place each day preferably at the same place, and typically held in the
morning. The purpose of the Stand-up is to keep everyone on the same page.

Each team member is being required to answer 3 questions:

 What did I do yesterday?

 What will I do today?
 Are there any impediments to continue working?

3. Sprint/Iteration Review
An agile ceremony held by Development Team, Scrum Master and Product Owner, where the
stakeholders may be invited as well. The purpose of the Iteration Review is to show the work
that the team has achieved in the last sprint. The format of the meetings can be casual or
formal depending on the team’s preferences.

4. Sprint Retrospective
An agile ceremony held after Sprint Review meeting and usually takes an hour. Participants are
Scrum Master, Product Owner, and Development Team. The aim of the meeting is to find out
what worked well and what didn’t, in the last iteration. The team tries to find out any issue that
is affecting the progress. All participants give written feedback. The team takes this session as
an opportunity to improve.

9. Sprint demo meetings

The sprint demo meeting is intentionally kept very informal, typically with rules forbidding the
use of PowerPoint slides and allowing no more than two hours of preparation time for the
meeting. A sprint review meeting should not become a distraction or significant detour for the
team; rather, it should be a natural result of the sprint.

Participants in the sprint demo typically include the product owner, the Scrum team, the Scrum
Master, management, customers and developers from other projects.
During the sprint demo, the project is assessed against the sprint goal determined during the
sprint planning meeting. Ideally, the team has completed each product backlog item brought
into the sprint, but it's more important that they achieve the overall goal of the sprint.

Purpose of sprint demo meeting

The purpose of the sprint review is for the development team to present to the Product Owner
and stakeholders what they accomplished during the last sprint. They will only present work
that they consider done. Done means the work just completed is potentially shippable or ready
for implementation by the user, and has been thoroughly designed, planned, coded, tested,
debugged, and documented. The work has also been checked to see that it is compatible and
can be inter-graded with work that has already been completed or is to be completed in the
near future.
The sprint review meeting starts with one team member stating the sprint goal and the product
backlog items the development team was committed to complete, and those actually
completed during the last sprint. Other team members can then discuss what went well and
what did not during the last sprint.

The majority of the sprint review meeting should be spent with the team describing what they
just completed and getting feedback from the Product Owner and stakeholders. Typical
questions the team should be interested in getting answers to are:

 What did the users like or dislike?

 What don’t they seem to understand?
 What do they want to be changed or deleted?
 What new things do they think would be good to add?
 Have their priorities changed?

10. Retrospective meetings

A retrospective is a meeting held by a software development team at the end of a project or

process to discuss success and failure and future improvements after each iteration. The goal of
retrospectives is helping teams to improve their working culture.

Scrum Master is the retrospective facilitator who is accountable for understanding the roles of
each member and remove difficulties to deliver the product goals successfully.

 Benefit of Retrospective meetings

 Retrospectives provide platform to celebrate success and ponder upon failures. Team members
can deliberate upon the course of improvements to be included in the next sprint. Retrospective
encourages participation, sharing of interests and views, taking the team towards an amicable
solution. End of a retrospective let’s the team to start the next sprint with a clean slate.
Agile Retrospective Meeting Steps
Retrospective meeting will involve the following steps:
 Set Stage – Organize meeting – Involves setting up of the meeting by the facilitator
(PM., scrum master, etc.) and sending a meeting invitation to all the required team
members and stakeholders.
 Gather Data – Once the meeting starts, gather all the ideas, opinions, concerns that the
team members might have. This can be done via various agile retrospective activities like
Start, Stop, and Continue, Paint Me picture etc.
 Generate Insights – After the data is gathered, meaningful analytics have to be
identified and patterns have to be created. The idea is to identify trends and resolve
them. E.g. if the team members are unhappy about the long daily stand-ups then we
have to figure out what is causing this. It could be unrelated discussions, the tardiness of
the team members, unrealistic time set up that does not accommodate the number of
updates, etc.
 Create Actions – Once the underlying issues are identified, create action points to
resolve them. Action points should be assigned to an accountable person(s) who will be
responsible to resolve it by the decided due date.
 Wrap Up – Thank the team for their time and for their participation. Make sure that the
meeting discussion and action points are documented and circulated to the team
members for easy reference.

11. Integration

The continuous merging of previous work with the present work, or merging of different
modules is known as Integration.

The Four Activities of Continuous Integration:

 Develop describes the practices necessary to implement stories and commit the code
and components to the trunk.
 Build describes the practices needed to create deployable binaries and merge the
development branches into the trunk.
 Test end-to-end describes the practices necessary to validate the solution.
  Stage describes the practices necessary to host and validate the solution in a staging
environment before production

Benefits:

 Prevent integration problems

 Integration bugs are detected early and are easy to track down due to small change sets.
This saves both time and money over the lifespan of a project
 Avoids last-minute chaos at release dates, when everyone tries to check in their slightly
incompatible versions
 Committing code frequently
 Categorizing developer tests
 Constant availability of a “current” build for testing, demo, or release purposes
 Frequent code check-in pushes developers to create modular, less complex code
 Enforces discipline of frequent automated testing
 Separate software builds from software deployments
 Say goodbye to long and tense integrations
 Increase visibility which enables greater communication
 Spend less time debugging and more time adding features

12. Test-driven development

TEST DRIVEN DEVELOPMENT (TDD) approach first, the test is developed which specifies and
validates what the code will do. In simple terms, test cases are created before code is written.
The purpose of TDD is to make the code clearer, simple and bug-free.

Test-Driven Development starts with designing and developing tests for every small
functionality of an application. TDD instructs developers to write new code only if an
automated test has failed. This avoids duplication of code. Test-Driven development is a
process of developing and running automated test before actual development of the
application. Hence, TDD sometimes also called as Test First Development.

How to perform TDD Test

Following steps define how to perform TDD test,

1. Add a test.
2. Run all tests and see if any new test fails.
3. Write some code.
4. Run tests and Refactor code.
5. Repeat.

TDD cycle defines

1. Write a test
2. Make it run.
3. Change the code to make it right i.e. Refactor.
4. Repeat process.

Levels of TDD

There are two levels of TDD

 1. Acceptance TDD (ATDD): With ATDD you write a single acceptance test. This test fulfills
the requirement of the specification or satisfies the behavior of the system.
2. Developer TDD: With Developer TDD you write single developer test i.e. unit test and
then just enough production code to fulfill that test.

The main goal of ATDD and TDD is to specify detailed, executable requirements for your
solution on a just in time (JIT) basis. JIT means taking only those requirements in
consideration that are needed in the system. So increase efficiency.

13. Burn-down chart

A burn-down chart is a graphic representation of how quickly the team is working through a
customer’s user stories, an agile tool that is used to capture a description of a feature from an
end-user perspective. The burn-down chart shows the total effort against the amount of work
for each iteration.

The quantity of work remaining is shown on a vertical axis, while the time that has passed since
beginning the project is placed horizontally on the chart, which shows the past and the future.
The burn-down chart is displayed so everyone on the team can see it and is updated regularly
to keep it accurate.

 Variations of the Burn-down Chart

There are two variants that exist for a burn-down chart. A sprint burn-down is for work
remaining in the iteration. When illustrating the work remaining for the entire project, the
chart is called a product burn-down.

Benefits of Burn-down Chart

 The obvious benefit of a burn-down chart is that it provides an updated status

report on the progress of the project. Having a visual representation of this most
important data keeps everyone on the same page.
 The burn-down chart is extremely helpful, too, because of its simplicity. It’s a
great way to see the velocity history of the project. 

Limitations of a Burn-down Chart

 The burn-down chart doesn’t reveal everything. For example, it only shows the number
of story points that have been completed. The burn-down chart doesn’t show any
 changes, for example, in the scope of work as measured by the total points in
the backlog.

 It can be hard to tell if changes in the burn-down chart are because of the backlog items
having been completed or because of an increase or decrease in story points.

14. Automated tests

Automated tests are the only way to achieve a sufficiently high test coverage in each sprint and
thus provide the high quality and rapid feedback that we seek when we are working Agile.

Practices of Automated Tests:

 Automation based on coverage: The scope of test automation depends on the amount
of code that has to be covered. As part of the test automation execution system, test
traceability can be easily understood through test automation runs that are based on
code-coverage.
 System level automation: In an agile workflow, dependent on team input and user
feedback, the UI is bound to experience many changes and multiple versions. So in
terms of UI maintenance, test automation tends to be very time-consuming. In order to
keep maintenance costs down and enhance overall coverage, automation needs to be
conducted at the level of systems and services.
 Development driven by testing: Testers need to work closely with product dev teams in
cases where the testers first design automation tests and make those tests the
foundation for the source code. Implementation of such testing therefore requires
persistent collaboration between the different teams.
 Automated testing before its manual counterpart: Before automated testing was as
widespread as it is now, a round of manual testing was necessary before implementing a
round of test automation. But in today’s fast-paced market with rigid demands, teams
don’t really have the time to engage in manual testing. They dive straight into the
automated environment, but in spite of the efficiency and thoroughness of this process,
 it would be a good idea for testers to conduct one manual run-through to confirm the
stability of the application and get rid of any glitches that the program may have
ignored.
 Choice of Tool: In an agile workflow, poor decisions and erroneous choices can have
detrimental effects that could take a long time to reverse. Selecting the right tools for
the job is absolutely key to ensuring successful test runs, and testers can choose from a
wide variety of commercial and open-source solutions. Apart from the suitability of a
particular tool to a particular automation issue, testers need to take into account a
number of other potential problems, such as integration capabilities, installation
requirements, overall cost, maintenance, and compatibility with the testing
environment.
 Verifying test automation code: The automation code itself needs to be tested to
ensure consistency and high quality. The code needs to be verified top to bottom, and
all issues must be eliminated before implementing a test of any product. In an agile
workflow, the pressing lack of time means that the code has to be flawless, and has to
guarantee low maintenance costs, reliability, and robustness. In test automation, each
step (tool choice, framework design, data generation, test design, code review,
execution, maintenance, etc.) is handled in a sequential flow, which means that any
automation program is conducted in a traditional testing environment by one single
tester who takes care of each step.
 Sharing code to encourage code usage across teams: Development, build, and
operations teams should ideally be kept in the loop with regard to any given automation
code. The advantages of such transparency are numerous – a general increase in the
focus on product quality, shorter test and dev cycles, and the free sharing of knowledge
to facilitate an efficient workflow. Bringing in people from the non-testing departments
brings in new perspectives and approaches to dealing with potential issues, and so the
automation code is more likely to be reliable.
 15. Requirement prioritization
Requirement prioritization is used in agile product management for determining which specific
product requirements should be included in a certain release.
Product managers also prioritize the requirements to minimize risks during development – the
most important requirements are implemented first. In this case, experienced product and
project managers use well-known prioritization methods and techniques.

Five Steps:

In the approach of Karlsson and Ryan, five steps for reviewing candidate requirements and
determining a priority among them are identified. These are summed up below.

 Requirement engineers carefully review candidate requirements for completeness and

to ensure that they are stated in an unambiguous way.
 Customers and users (or suitable substitutes) apply AHP’s pairwise comparison method
to assess the relative value of the candidate requirements.
 Experienced software engineers use AHP’s pairwise comparison to estimate the relative
cost of implementing each candidate requirement.
 A software engineer uses AHP to calculate each candidate requirement’s relative value
and implementation cost, and plots these on a cost-value diagram. Value is depicted on
the y axis of this diagram and estimated cost on the x-axis.
 The stakeholders use the cost-value diagram as a conceptual map for analyzing and
discussing the candidate requirements. Now software managers prioritize the
requirements and decide which will be implemented
 16. In-pairs programming
Pair programming consists of two programmers sharing a single workstation (one screen, keyboard
and mouse among the pair). The programmer at the keyboard is usually called the “driver”, the
other, also actively involved in the programming task but focusing more on overall direction is the
“navigator”; it is expected that the programmers swap roles every few minutes or so.

Common Pitfalls

 Both programmers must be actively engaging with the task throughout a paired session,
otherwise no benefit can be expected
 A simplistic but often raised objection is that pairing “doubles costs”; that is a
misconception based on equating programming with typing – however, one should be aware that
this is the worst-case outcome of poorly applied pairing
 At least the driver, and possibly both programmers, are expected to keep up a running
commentary; pair programming is also “programming out loud” – if the driver is silent, the
navigator should intervene.

The Pros of Pair Programming

 Fewer mistakes and bugs

Software developers usually work alone, which can cause negative traits like
stubbornness and tunnel vision. It’s all too easy to get stuck when trying to fix a bug
based on an incorrect assumption, a hidden typo, or a gap in your knowledge. When
we’re pair programming, however, we’re forced to work as a team. This
automatically gives the code more “quality control.” 

 Increased code quality

Pair programming encourages teams to build robust solutions that won’t create
unexpected bugs later on.

 Faster training

The partners for pair programming are usually two experts or one expert and one
novice. In this latter case, pair programming allows junior and new team members to
pick up information from their more experienced colleagues
  Improved team morale

Finally, pair programming gives you someone else to talk to on the project who can empathize
with you and help you solve your problems, so that you aren’t stuck spinning your wheels all
day. This helps make the team as a whole more productive and happier

The Cons of Pair Programming

Higher costs

Having two people working on a single initiative may seem like a waste of valuable resources.
Indeed, it’s true that pair programming won’t be able to complete a project in half the time.
Still, the greater overhead that pair programming incurs is typically balanced by the higher-
quality code and a more efficient, effective final result.

 Sustainability

Pair programming isn’t usually sustainable enough to be practiced all of the time. The ideal
amount of time to spend pair programming seems to be around 2 to 2.5 hours—and don’t
forget to take breaks.

17. Release Planning

The purpose of release planning is to create a plan to deliver an increment to the product. It is
done after every 2 to 3 months. It involves:
 Scrum Master − the scrum master acts as a facilitator for the agile delivery team.
 Product Owner − the product owner represents the general view of the product
backlog.
 Agile Team − Agile delivery team provides insights on the technical feasibilities or any
dependencies.
 Stakeholders − Stakeholders like customers, program managers, subject matter experts
act as advisers as decisions are made around the release planning.
Prerequisites of Planning
The prerequisites of release planning are as follows −
 A ranked product backlog, managed by the Product Owner. Generally five to ten
features are taken which the product owner feels that can be included in a release
 Team's input about capabilities, known velocity or about any technical challenge
  High-level vision
 Market and Business objective
 Acknowledgement whether new product backlog items are needed
Materials Required
The list of materials required for release planning is as follows −

 Posted agenda, purpose

 Flip charts, whiteboards, markers
 Projector, way to share computers having data/tools required during planning meeting
 Planning data
Planning Data
The list of data required to do release planning is as follows −

 Previous iterations or release planning results

 Feedback from various stakeholders on product, market conditions, and deadlines
 Action plans of previous releases / iterations
 Features or defects to be considered
 Velocity from previous releases/ estimates.
 Organizational and personal calendars
 Inputs from other teams and subject matter experts to manage any dependencies
Output
The output of a release planning can be the following −

 Release plan
 Commitment
 Issues, concerns, dependencies, and assumptions which are to be monitored
 Suggestions to improve future release planning.

Q.3. Search and Add more best Practices for Agile Methodologies. (One page each for them)

1. Using Professional Tools

Using project management tools for the implementation of agile methodologies helps the team
to better structure their workflows and improve team collaboration. For proper documentation
and meetings management, a professional project management software can greatly reduce
the effort it takes to manage your tasks otherwise.
One such tool that you can easily use is n-Task. A comprehensive software, with the most
intelligent features, provides a smart over-all coverage to all your agile project management
needs.

2. Refactoring

Code Refactoring is the process of clarifying and simplifying the design of existing code, without
changing its behavior. Agile teams are maintaining and extending their code a lot from iteration
to iteration, and without continuous refactoring, this is hard to do.

Refactoring Principles:

 Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large
batches. The worst extreme is the complete system re-write refactoring. The best refactoring
activities take seconds or minutes to execute. Small refactoring creates a constant modest
“overhead” in the work of the team.

 Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants
to do it. Instead, the technical team needs to use business requests as catalysts for refactoring.
If the business needs a new feature, then refactoring should only be done on those parts of the
system that are required to enable that feature.

 Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration. In refactoring

work, teamwork applies just as much as in any other activity.

 Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open
and honest with all stakeholders about the cost of refactoring. This can be difficult at first.
Another analogy helps to see the value of this.

3. Simple code design

When writing code, agile developers often stop to ask themselves, "What is the simplest thing
that could possibly work?" They seem to be obsessed with simplicity. Rather than anticipating
changes and providing extensibility hooks and plug-in points, they create a simple design that
anticipates as little as possible, as cleanly as possible. Unintuitive, this results in designs that are
ready for any change, anticipated or not.
In the first edition of Extreme Programming Explained, Kent Beck described simple design as
code that passes its tests and meets four guidelines, with the earlier guidelines taking
precedence over the later ones.

1. The system (code and tests together) must communicate everything you want to
communicate.
2. The system must contain no duplicate code. (1 and 2 together constitute the Once and
Only Once rule).
3. The system should have the fewest possible classes.
4. The system should have the fewest possible methods.

In the second edition, he rephrased the advice.

1. Appropriate for the intended audience. It doesn't matter how brilliant and elegant a
piece of design is; if the people who need to work with it don't understand it, it isn't
simple for them.
2. Communicative. Every idea that needs to be communicated is represented in the
system. Like words in a vocabulary, the elements of the system communicate to future
readers.
3. Factored. Duplication of logic or structure makes code hard to understand and modify.
4. Minimal. Within the above three constraints, the system should have the fewest
elements possible. Fewer elements means less to test, document, and communicate.

4 .System Metaphor

System metaphor is a story that everyone - customers, programmers, and managers - can tell
about how the system works.

Need of System Metaphor:

We seek a system metaphor for several reasons:

 Common Vision:
To enable everyone to agree on how the system works. The metaphor suggests the key
structure of how the problem and the solution are perceived. This can make it easier to
understand what the system is, as well as what it could be.
 Shared Vocabulary: The metaphor helps suggest a common system of names for objects
and the relationships between them. This can become a jargon in the best sense: a
powerful, specialized, shorthand vocabulary for experts. Naming something helps give
you power over it.
To the end of the line – does it just fall off?” This can bring out important issues that
might otherwise lurk and fester.
 Architecture:
The metaphor shapes the system, by identifying key objects and suggesting aspects of
their interfaces. It supports the static and dynamic object models of the system.
 
 
.