7 Distributed Agile

Agile Software Development
(ASD) Lect-8
Prof. Daiwat Vyas
B.TECH SEMESTER 6TH CSE

Product v/s Release v/s Sprint Backlog?
•Product Backlog
• The agile product backlog in Scrum is a prioritized features list.
• Containing short descriptions of all functionality desired in the product.
• 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.
• These items can have a technical nature or can be user-centric
2
• Product backlog Properties

• An entry in the Scrum Product Backlog always add value for the customer
• The entries in the Scrum Product Backlog are prioritized and ordered accordingly
• The level of detail depends on the position of the entry within the Scrum Product
Backlog
• All entries are estimated
• The Scrum Product Backlog is a living document
• There are no action-items or low-level tasks in the Scrum Product Backlog
3
• Product backlog Properties

• An entry in the Scrum Product Backlog always add value for the customer
• The entries in the Scrum Product Backlog are prioritized and ordered accordingly
• The level of detail depends on the position of the entry within the Scrum Product
Backlog
• All entries are estimated
• The Scrum Product Backlog is a living document
• There are no action-items or low-level tasks in the Scrum Product Backlog
4
• A typical Scrum backlog comprises the following different types of items:
• Features
• Bugs
• Technical work
• Knowledge acquisition
• The predominant way for a Scrum team to express features on the agile product backlog
is in the form of user stories.
• Because there's really no difference between a bug and a new feature bugs are also put on
the Scrum product backlog.
• Technical work and knowledge acquisition activities also belong on the agile backlog
• Example of technical work : Upgrade all developers' workstations to Windows 7.
• Example of Knowledge Acquisition: A scrum backlog item about researching various
JavaScript libraries and making a selection.
5
• The product owner shows up at the sprint planning meeting with the prioritized
agile product backlog and describes the top items to the team. The team then
determines which items they can complete during the coming sprint.
• Attributes for good product backlog (DEEP)
• Detailed Appropriately
• Estimated
• Emergent
• Prioritized
6
Visualize the Product backlog with Treemap
• Suppose you have a very large product backlog--such as one with lots of themes
(groups of related user stories) or being worked on by multiple agile teams.
• The best way to visualize this product backlog is with a treemap.
• Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of

visualizing hierarchical (that is, tree-structured) data.
• In the following slide a simple treemap of a two-story house is demonstrated:
7
• Suppose you have a very large product backlog--such as one with lots of themes
(groups of related user stories) or being worked on by multiple agile teams.
• The best way to visualize this product backlog is with a treemap.
• Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of

visualizing hierarchical (that is, tree-structured) data.
• In the following slide a simple treemap of a two-story house is demonstrated:
8
• What Is (User) Story Mapping?

Story Mapping or User Story Mapping is a technique used in product discovery:
outlining a new product or a new feature for an existing product.
• The result is a Story Map: all the user stories arranged in functional groups.
• This helps you keep your eye on the big picture while also providing all the details
of the whole application.
9
• What’s the Purpose of Story Mapping?

The main purpose of Story Mapping is to facilitate product discovery and
prioritization of development work.
You achieve this by putting user activities and tasks on a map that serves to keep
them in context.
• The Story Map always shows how each individual story fits in the whole
application.
• And this makes it easy to spot gaps and decide how important one is over another.
10
• What agile values and principles does story mapping support?

Story Mapping supports two values of the Agile Manifesto. “Customer
collaboration over contract negotiation” and “Responding to change over
following a plan”.
• You get the best results when you collaborate with a (future) user or a domain
expert. Someone who is intimately familiar with the work that your application is
to support and the problems it’s to solve.
• Using Story Mapping, it’s easy to respond to change. Because when you add a new
user story, or you change or remove an existing one, it’s easy to spot what else
needs to be added, changed, or removed.
11
• Who Created Story Mapping?

• Jeff Patton first described Story Mapping in his “It’s All in How You Slice it” article
in 2005 when he’d already been using it for a couple of years.
• But he didn’t call it Story Mapping then. He coined that term in his “The New
User Story Backlog Is a Map” article of 2008.
• He also wrote a book about it: “User Story Mapping: Discover the Whole Story,
Build the Right Product”.
12
• Why Use Story Mapping?

• What Problems Does Story Mapping Solve?
• When you finish your product discovery, you’ll likely put the user stories into the
backlog of a Scrum
• That’s fine to drive the development effort once you’ve decided on the build order.
• However, the backlog management capabilities of these tools fall short for
product and release management. Simply because the backlog is shown as a long,
flat list. The filtering, labelling, and coloring you can do, helps a bit, but you
never get the whole picture.
• Story Mapping solves this by arranging user stories in a simple helpful layout.
13
• What (Other) Benefits Do You Get Out of Story Mapping?

• Story Mapping gives you a number of direct and indirect benefits.
• Everyone can easily understand the whole application—generally the most
difficult part of software development. The Story Map tells the story of what your
application solves and how it does it for anyone who’s interested. Everyone can
participate in creating it.
• You keep the big picture of your application in full view—losing the big picture
is a common complaint in agile teams.
• Putting together and having a Story Map visible encourages iterative and
incremental development.
14
• Having the big picture at your fingertips
• shows you where a user story fits in the whole system in a single glance.
• helps you decide what to build first. A Story Map makes it easy to pick and choose user stories
from different features that together will provide meaningful value. This means you can
confidently determine the scope of and build an MVP or a useful release.
• means you can more easily avoid building something that doesn’t work. You won’t get lost or forget
important parts that would effectively render it unusable, like a car without brakes. For example,
because you delayed low-value stories that your high-value stories depend on.
• lets you walk the Story Map to test it for gaps: spot more easily where something is missing.
• lets you make prioritization decisions taking the context of the whole system into account.
• means you’ll avoid staring yourself blind on a single user story.
15

• When you create a physical Story Map, you get some more benefits.
• The map becomes a focal point for collaboration and helps shared
understanding.
• The full context provided by the map helps to quickly size user stories relative to
each other.
• You can add smaller stickie's to user story cards to add extra information or mark
stories for the current and next iteration.
16
• Pitfalls and Mistakes
• The most important pitfalls and mistakes with Story Mapping are:
• Working without a customer or someone intimately familiar with their work
• You need to collaborate with someone that uses or will use your product to support their
work.
• Without their input and perspective, you’ll be guessing at what’s important and what’ll
provide real value. You’ll be playing a hit and miss game and will likely waste
development effort.
• No goal, no problem to solve
• Working without a problem to solve, a goal to reach, you have nothing to guide your
decisions and you’ll have no idea when you’re done. Leading to wasted effort, or at least to
expending effort on something at the wrong time.
17
• Not keeping the map visible

• Out of sight, out of mind. Without the Story Map serving as a visible reminder of
your application’s big picture, veering off course is all too easy.
• As is the danger of getting lost in the weeds: getting caught up in the details of a
single story that are irrelevant for the whole. This hurts even more, when those
details would take more effort than the value of the story merits.
• While a physical Story Map is preferable for the extra benefits it provides, with so
many remote teams nowadays, you won’t always have that luxury. But you can still
keep it highly visible.
• You can for example have a dedicated, large monitor showing the map in every
location where you have team members.
18
• In the given treemap, each rectangle is sized to represent the relative area of the
room.
• From it you can see that the master bedroom is about twice the size of either kid's
room and a little larger than the downstairs family room.
• The combined green area of the downstairs rooms is slightly larger than the area
of blue upstairs rooms.
• From this very simple treemap you can get a feel of certain aspects of this house.
To visualize a product backlog with a treemap we need to conceptualize it as
hierarchical data.
19
• We can do this a couple of different ways. For example,
• Rental Car Theme
• As a traveller, I can rent a car
• As a traveller, I can get collision insurance on a car rental policy.
• As a traveller, I can request a baby car seat be inside my car.
• Airplane Theme
• As a traveler, I can request an aisle seat.
• As a frequent flyer, I can request an upgrade to first class.
• Or we could create a product backlog as a tree with levels for
• Team
• Product Backlog Items Being Worked On By That Team
20
• The following figure in next slide shows a product backlog as a treemap. There are
five themes in the treemap. (Theme 4 is in the top left; Theme 1 is in the bottom
right)
21
• The following figure in next slide shows a product backlog as a treemap. There are
five themes in the treemap. (Theme 4 is in the top left; Theme 1 is in the bottom
right)
22
• The size of each story in the preceding figure represents the number of story
points that the story was assigned when estimated. Colors can be used on a
treemap to represent an additional attribute of the data.
• One color coding that can be used is :
• Done
• Started but not done
• Not started but not planned to have been started yet
• Not started but it should have been started by now
• Blocked
23
• Use color to indicate which team would work on a user story / product backlog
item or whether the item was ready for development or not. Treemaps are very
flexible in this regard.
24
From Sprint Goal to Sprint Backlog
• Scrum team takes the Sprint Goal and decides what tasks are necessary
• Team self-organizes around how they’ll meet the Sprint Goal
• Manager doesn’t assign tasks to individuals
• Managers don’t make decisions for the team

• Sprint Backlog is created
25
Sprint Backlog
• A subset of Product Backlog Items, which define the work for a Sprint.
• Is created ONLY by Team members.
• Each Item has it’s own status.
• Should be updated every day.
• No more then 300 tasks in the list.
• If a task requires more than 16 hours, it should be broken down.
• Team can add or subtract items from the list. Product Owner is not allowed to do
it.
• Most teams also estimate how many hours each task will take someone on the
team to complete.
26
Sprint Backlog
• Creating a Good Sprint Backlog- needs following things
• Involve every team member in the process.
• Discuss how every item should be implemented
• Have a definition of done.
• Identify all kinds of tasks.
• Don't estimate tasks at all.
• Don't assign tasks up front
• Review the sprint commitment.
• Don't use too much time
• Evolve the Sprint Backlog during the sprint.
27
Scrum Release planning
• To create a Release Plan the following things have to be available

• A prioritized and estimated Scrum Product Backlog
• The (estimated) velocity of the Scrum Team
• Conditions of satisfaction (goals for the schedule, scope, resources)
• Like the Scrum Product Backlog the Release plan is not a static plan. It will
change during the whole project when new knowledge is available and e.g. entries
in the Scrum Product Backlog are changed and re-estimated.
• Therefore the Release Plan should be revisited and updated in regular intervals,
28
Project Velocity
Velocity is the number of story points completed by a team in an iteration.
𝑇𝑜𝑡𝑎𝑙 𝑆𝑡𝑜𝑟𝑦 𝑝𝑜𝑖𝑛𝑡𝑠

• Velocity =
𝑛𝑜 𝑜𝑓 𝑠𝑝𝑟𝑖𝑛𝑡𝑠
• Here velocity = 105.6 Story points/Sprint

• We need velocity to:
• Predict how much scope can be delivered by a specific date
• Predict a date for a fixed amount of scope to be delivered
• Understand our limits while defining the amount of scope we will commit for a
sprint
29
Project Velocity
• What influences velocity?

• As in a car trip, there are factors that may influence our velocity:
• Roadblocks -- aka impediments
• Fuel -- motivation, what drives us
• Driver experience -- knowledge/expertise/competence developer
• Car conditions -- development environment
• Visibility -- project transparency
• Directions -- project objectives
• Traffic/driving rules -- processes
• Destination -- product
30
Burn down Charts
• Are used to represent “work done”.

• Are wonderful Information Radiators
• Types:
• Sprint Burn down Chart (progress of the Sprint)
• Release Burn down Chart (progress of release)
31
Burn down Charts
• X-Axis: time (usually in days)

• Y-Axis: remaining effort
32
Sprint Burn down Chart
• Depicts the total Sprint Backlog hours remaining per day

• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of the Sprint
• Actually is not a straight line
33
Release Burn down Chart
• Will the release be done on right time?

• X-axis: sprints
• Y-axis: amount of hours remaining
• The estimated work remaining can also burn up
34
Alternative Release Burn down Chart
• Consists of bars (one for each sprint)

• Values on the Y-axis: positive AND negative
• Is more informative then a simple chart
35
Alternative Release Burn down Chart
• Consists of bars (one for each sprint)

• Values on the Y-axis: positive AND negative
• Is more informative then a simple chart
36
Distributed & Large Scrum Projects
37
• In reality a single Scrum Team often cannot realize projects or resources are
spread over multiple locations.
• As a consequence the number of teams has to be increased and/or the teams will
be distributed.
resources are spread over multiple locations.
cannot realize projects
• The reasons for this can be ??????? number of team has to be increased and team
will be distributed.
38
• In reality a single Scrum Team often cannot realize projects or resources are spread over
multiple locations.
• As a consequence the number of teams has to be increased and/or the teams will be
distributed.
Experts are not locally available
• The reasons for this can be ????? size-related
• technical (e.g. experts are not available locally) business related (low cost,time zone)
• size-related (project too big)
• business-related (e.g. usage of resources in low-cost countries or speed-up by usage of different
time-zones).
• What will be the problem/s that the team will face in this framework?
• As communication is an integral part of the Scrum Framework, Therefore all team
members should have access to the appropriate communication tools (e.g. video
conferencing and web cams) to breaking down the more tangible communication
barriers.
39
• Issues/Challenges involved in implementing SCRUM in distributed

environment?
40
• Issues/Challenges
• Communication:
• One of the biggest challenges in distributed and large Scrum projects is
communication.
• With team members spread across different locations and time zones, it can be
difficult to ensure that everyone is on the same page and has access to the same
information.
• This can lead to misunderstandings, delays, and mistakes.

41
• Coordination:
• In large Scrum projects, it can be challenging to coordinate the work of multiple

teams and ensure that everyone is working toward the same goals.
• This can be further complicated by the fact that different teams may have
different priorities or be working on different parts of the project.
42
• Integration:
• In distributed and large Scrum projects, integrating different components and

subsystems can be a major challenge.
• This requires close collaboration between different teams, as well as careful

planning and testing to ensure that everything works together seamlessly.
43
• Scalability:
• As the size of a Scrum project grows, it can become more difficult to scale the
process to accommodate larger teams or more complex requirements.
• This can require changes to the Scrum framework or the adoption of additional
tools and practices.
44
• Knowledge sharing:
• In large Scrum projects, there may be team members with different areas of
expertise or specialized knowledge.
• It can be challenging to ensure that this knowledge is shared across the team and
leveraged effectively.
45
• Time zones:
• Distributed Scrum projects can also face challenges related to time zones.
• Team members may need to coordinate their schedules to ensure that they can
collaborate effectively, and this can be complicated by factors such as daylight
savings time or holidays in different regions.
46
• Cultural differences:
• When working with distributed teams, it's important to be sensitive to cultural

differences and ensure that everyone feels comfortable and included.
• This may require additional efforts to build trust and establish effective
communication channels.
47
• Overall, successfully managing a distributed and large Scrum project

requires careful planning, effective communication, and close
collaboration between different teams and stakeholders.
• It also requires a willingness to adapt and iterate the process as needed to

ensure that the project stays on track and meets its goals.
48
• How can issues involved in Distributes and Large SCRUM projects be

resolved or handled ? List key points
49
• Key points to consider:
• Establish clear communication channels:
• Communication is crucial for any project, but even more so in distributed and
large projects.
• Ensure that everyone has access to the same communication tools and establish
clear guidelines for communication, including when and how often team
members should check in with each other.
50

• Use collaboration tools:
• There are many collaboration tools available that can help facilitate
communication and collaboration, such as video conferencing, project
management software, and team collaboration software.
• Choose the tools that work best for your team and make sure everyone knows
how to use them.
51
• Break the project down into smaller chunks:
• Breaking the project down into smaller, more manageable pieces can help make
the project more manageable and easier to track progress.
• This also allows for more frequent opportunities to review and adjust the project
plan.
52
• Use Scrum ceremonies/events properly:
• Scrum ceremonies such as daily stand-up meetings, sprint planning meetings,

and retrospectives can help keep the team aligned and focused on the project
goals.
53
• Emphasize team building:
• In distributed and large projects, team building can be challenging, but it is

crucial to the success of the project.
• Plan team-building activities such as team lunches, virtual happy hours, and
team-building exercises to help build relationships and improve collaboration.
54
• Assign clear roles and responsibilities:
• Make sure that each team member understands their role and responsibilities in
the project, and ensure that there is clear accountability for each task.
55
• Assign clear roles and responsibilities:
• Make sure that each team member understands their role and responsibilities in
the project, and ensure that there is clear accountability for each task.
56
• Emphasize continuous improvement:
• Encourage the team to regularly review the project and identify areas for
improvement.
• This can help ensure that the project stays on track and that the team is
continually learning and growing.
57
Project Organization : Multiple Teams
• The simplest way of extending the Scrum Framework when working in a
large-scale project is to increase the number of teams in the same location.
Continue
• If multiple teams have to be used to implement the requirements it is important
to make sure that the number of teams does not grow too fast.
• Best is to start with a single team and after the first sprints have been completed
adding a small number of other teams.
• If required after these teams are productive other teams could be added.
• For creating new teams there are two possibilities:
• Splitting an existing team into new teams and add new members
• Adding completely new teams
Continue
• Splitting an existing team has the advantage that the required know-how is
already available in the team and the team can get productive faster. The
drawback is that already working teams are torn apart.
• When adding completely new teams, these existing teams can continue with
their work without much disruption. However, it will take longer to build up
the necessary system-know-how in the new Scrum Team.
• Independent from the decision how to add new teams the following rules
should be followed:
• Start with a small number of teams
• Always wait until a foundation is build and the teams have stabilized
• Increase the number of teams in small steps
Project Organization: Distributed Team from 03 April
2023
• Even more complicated it will get if these new teams are distributed over
multiple locations. Now also more often communication obstacles will occur
and special care has to be taken to introduce and involve all team members
adequately.
Continue
• To make sure that new team members are introduced adequately and
build-up the required knowledge as fast as possible, new team
members could e.g. temporarily added to an existing team, preferably
even in another location.
• With this approach the know-how is transferred and personal
relationships with people in other teams and locations build.
Virtual Teams
• Another possibility for distribution is that the team itself is spread over
multiple locations. Such a team is called a "virtual team".
Continue
• The main challenge here is to ensure good communication between the
team members since some people might not be able to physically
participate in meetings or have no access to "communication helpers"
like the Sprint Board.
• One possibility would be to use collaboration and/or communication
tools. Co-located people could then e.g. be added to meetings via video
conferencing or the meetings could even be performed completely in a
'virtual room' provided by most collaboration platforms.
Scrum Product Owner Team
• Proper communication between the Scrum Product Owner and the team is
crucial for successful implementation of the project.
• To ensure that the Scrum Product Owner is always available to the team, it is
often necessary to have multiple Scrum Product Owners working together.
• Ideally there is one dedicated Scrum Product Owner per team.
• The Scrum Product Owners should then build a dedicated Scrum Product
Owner Team to effectively work together.
• One of the Scrum Product Owners should be assigned the role of the 'Chief
Scrum Product Owner' who is responsible to ensure that the product is
developed in a coordinated fashion.
Continue
• Since this team is responsible for the complete requirement engineering it
might also be beneficial to add other roles and stakeholder like architects or
customer representatives.
• All Scrum Product Owners should work within a single Scrum Product
Backlog containing all stories relevant for the project.
Component or Feature Teams
• When distributing work we can slice the teams in different manners: as Component or
Feature teams.
• Component Teams:
• When using Component teams each team is only responsible for the implementation of
dedicated components in the system.
• To finish a user story it is in most cases necessary to split the stories into smaller pieces
that could be implemented within a single component.
• The resulting dependencies between the teams make integration on a regular base
necessary.
• In some of the cases a single user story cannot be finished within a single sprint as
implementation in one team depends on the results of other stories in other team that
are not yet available.
• This is called "Pipelining" and should be avoided as far as possible.
• Advantage of using component teams is
that it is easier to ensure proper
Continue architecture of the system.
• On the other hand people specialize only
on small parts of the system and
knowledge about the system as a whole
might get lost.
• Without this knowledge local optimization
might take place since the team might
sometimes make decisions that are
optimized for the single component but
better solutions from a system perspective
could have been made.
Feature Teams
• Feature teams are fully responsible for implementation of user stories
as contained in the Scrum Backlog.
• The team is not longer sliced along system components but implement
everything what is necessary to finish the story.
Continue
• Feature teams have to be interdisciplinary and ideally can act
completely autonomous.
• The advantage is that system-knowledge is spread and integration is
easier. However it is more difficult to ensure consistency of the system
architecture and it might be difficult or takes time to ensure that
enough knowledge is available in all teams.
Component and Feature Teams
• In reality many larger projects use both: dedicated Component teams
and Feature teams. • Team C is a Component team and provides
necessary infrastructure services to the
other teams that are used as Feature teams.
• Team C does not directly implement user
stories but get the requirements from the
user stories committed by the Feature
teams.
• This allows minimizing the number of
required people with expert knowledge
(e.g. databases know-how).
The Scrum Master in a Distributes Environment
• In a distributes environment the role of the Scrum Master is even more
important as such setups usually have more impediments that require
the Scrum Masters attention and effort.
• One important rule is that the Scrum Master has to be located where
the team is otherwise it will be difficult to remove the obstacles in daily
work.
• There should always be a primary Scrum Master, but in virtual teams it
might also be an option that on the remote site one person acts as a
local Scrum Master.
Multi-Team Coordination & Planning
• Scrum of Scrum from 10 April 2023
• To coordinate the different Scrum Teams "Scrum of Scrum"-Meetings can be
used. It is similar to the Daily Scrum but the focus here is on team-level.
• The meeting takes place every day and should be limited to e.g. 15 minutes. Each
team sends out one member to participate and answer the following questions:
• What did the team finish?
• What does the team plan to finish today?
• Are there any impediments?
• The answers should concentrate on the things that impact any other team.
• The Chief Scrum Product Owner should moderate the meeting. Participate
should not only the Scrum Master of the teams, one approach could also be to
shift participation on a daily base within the team.
Continue
• Instead of multiple small Sprint Review meetings a common Sprint
Review with all teams could also be used. This will show everyone what has
been done within the Sprint and what the status of the project is.
• For the Sprint Retrospective there are two possibilities. The first possibility is
that each team has their own Sprint Retrospective meeting followed by a
Common Sprint Retrospective where all results are discussed that concern
multiple teams.
• Another possibility is that topics are collected, selected and then worked on
in smaller groups with members of all teams. This approach will take more
time but the advantage is that members from multiple teams are closely
working together.
Multi-Team Planning - Scrum Product Backlog
• Even when working with multiple teams it is important to keep only
one common Scrum Product Backlog for all teams.
• The Scrum Product Backlog shall be maintained by the Chief Scrum
Product Owner but is filled by all Scrum Product Owners.
• If necessary the items in the Scrum Product Backlog can be broken
down into more team-specific stories and maintained in a team-
specific Scrum Product Backlog,
• e.g. only the relevant parts for an infrastructure team. In this case
references between these Scrum Product Backlogs shall exist.
Continue
Sprint Scheduling
• In a distributed Scrum environment it is possible to choose how to
synchronize the different teams.
• One possibility is to use synchronous sprints. In this case all teams
start and end their sprints on the same day.
Continue
• Synchronous Sprints are the easiest approach since it makes communication
and coordination simpler.
• Another possibility is to use asynchronous sprints. Here the sprints do not
start on the same day.
• Using asynchronous sprints has the advantage that not all meetings have to
be performed on the same day and makes it possible for e.g. the Scrum
Product Owners to participate in more of these meetings.
• When one team provides services to other teams asynchronous Sprints might
also be a good option because here the results of the service-providing team
is already available during the development time of the other teams and
could be integrated.
Continue
What is Project Velocity in Scrum?
• Velocity is an extremely simple, powerful method for accurately measuring the rate
at which scrum development teams consistently deliver business value.
• It is an indication of the average amount of Product Backlog turned into an

Increment of product during a Sprint by a Scrum Team, tracked by the
Development Team for use within the Scrum Team.
• Thus, to calculate velocity of your agile team, simply add up the estimates of the
features, user stories, requirements or backlog items successfully delivered in an
iteration.
• It should help the team:
• Predicting how much scope can be delivered by a specific date.
• Predicting a date for a fixed amount of scope to be delivered.
• Understanding our limits while defining the amount of scope we will commit for a
sprint.
• Scrum Velocity Example
• There are some simple guidelines for estimating initial velocity of your Scrum team
prior to completing the first few iterations, but after that point your team could use
proven, historical measures of velocity estimation for sprint planning.
• Based on a series of past sprints, the estimation of velocity typically stabilizes and
provides a more reliable basis for improving the accuracy of both short-term and
longer-term planning of your Scrum projects
• Note That:
• Velocity is a measure of the amount of work a Team can tackle during a single
Sprint and is the key metric in Scrum.
• Velocity is calculated at the end of the Sprint by summing up the Points for all fully
completed User Stories.
• Points from partially-completed or incomplete stories should not be counted in
calculating velocity.
• Step1 – Calculate the Velocity of the First iteration (Sprint)
• At the end of each iteration, the team adds up effort estimates associated with user
stories that were completed during that iteration. This total is called velocity.
• An agile team has started work on an iteration, planning to complete stories A and
B, estimated at 2 points each, and story C, estimated at 3 points.
• At the end of the iteration, stories A and B are 100% complete but C is only 80%
complete. Agile teams generally acknowledge only two levels of completion, 0%
done or 100% done.
• Therefore, C is not counted toward velocity, and velocity as of that iteration is 4
points.
• Step 2 – Use the Velocity to estimate number of iteration needed
• After knowing velocity in step 1, the team can compute (or revise) an estimate of
how long the project will take to complete, based on the estimates associated with
remaining user stories and assuming that velocity over the remaining iterations will
remain approximately the same.
• This is generally an accurate prediction, even though rarely a precise one.
• Suppose the user stories remaining represent a total of 40 points; the team’s
forecast of the remaining effort for the project is then 10 iterations.
• Relationship of Velocity and Story Point in Scrum
• Relationship of Velocity and Story Point in Scrum
• Story points are used to measure size and complexity which mean how long it takes
us to finish it.
• Story point is a relative measure of the time it takes to complete a user story. It is a
concept borrowed from XP.
• It is used to assess the difficulty of the story, not the promise of how long it will
take.
• This is regardless of the size of the team or what is the task, you can use story
points.
• Relationship of Velocity and Story Point in Scrum from 23 march 2022
• How to relate velocity to story point?
• Teams often need to use “Velocity” as a measure of productivity to tell outsiders
exactly how fast the Scrum team is.
• If the estimation of our story point is maintained throughout the project, it
would make sense to use the story point to represent “Velocity”.
• If the consistency is not only in the team, but also in the cross team, even at the
level of the entire company. This will not only measure productivity, but also
compare the status of each team.
• If the value of the story point is stable, then it can be used as a reference for the
release planning. You can evaluate the possible schedules afterwards.
• How to Determine Story Points for User Stories?
• Story points are a relative measurement unit, the first step your team should take is
to define one story as the baseline, so that they can estimate the other stories
comparing to that reference.
• According to the literature, the team should find the simplest story in the backlog,
and assign 1 story point to it, after that, they use that story as baseline to estimate
the other stories.
• There are two types of scales used for creating estimation of user story point:
• Linear scale (1,2,3,4,5,6,7…)
• Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13 …)
• It is a good idea to estimate the first user story that your team is familiar and should
know how much time needed for the story to be completed.
• Then you estimate you’re the next user story.
• If your team decides it is smaller than the baseline user story, so you place it on the
left side of the baseline story.
• Then you estimate again another user story.
• Support the team decides that it is also smaller than the baseline story, but bigger
than the second story – so you place the third story in the middle of the baseline
user story and the second user story.
• In the example, we use Fibonacci sequence numbers for story estimation:
• How to Estimate Velocity More Accurately?
• In Scrum, velocity help you to understand how long it will take your team to
complete the product backlog.
• However, it typically takes few sprints for the team figure out a more stable velocity.
• To estimate more accurate velocity for your team, we can gain the experience based
on the past track-record of the team.
• It will be more accurately forecasting of how many stories a Team can do in a
Sprint.
• For forecasting purposes the average of the last three or four Sprint’s Velocity
should be used.
• Suppose the new Scrum Team planned to complete 41 story points in their very first
sprint.
• They eventually can only completed 38 story points, and rolled 6 story points over
to the next sprint. So their velocity is 38 as shown in the Figure below:
• Averaging the Velocity Based on Past Sprint Track Record
• As mentioned before, the team should not add any partially-completed work
towards the velocity. Only those user stories marked as ‘Done’ count, even if there’s
only a tiny bit of work left to do in the task.
• Based on just only one sprint, the velocity is not a very reliable metric for making
predictions.
• (But it does give the team a sense of how much work they can commit to in a single
sprint.) Let’s track their progress for a few more sprints.
• Now, the new team continuous the subsequently development from Sprint 1 – 4 and
the story points in their first sprint is 38, 29 in their second, 38 in their third, and 39
in their fourth. So the estimation average of velocity after 4 sprints is 36 as shown
the Figure below:
• This average, over just four sprints, is already much more useful than the snapshot
we had after just one sprint.
• It’s easy to imagine how, with a backlog of already-estimated user stories, we could
use this velocity to make predictions.
• We could predict how quickly the team could get through all the work.
• And we could make educated guesses about what features we’d be able to deliver in
upcoming releases.
• Velocity Chart
• If a Scrum team has completed multiple sprints, the team can forecast release and
product completion dates and plan future projects more accurately by reviewing
the velocity report. Based on the velocity of previous sprints that the report
illustrates, you can accomplish the following goals:
• Track how much effort your team has reported as complete for each sprint.
• Estimate how much backlog effort your team can handle in future sprints if your
team composition and sprint duration stay constant.
• Velocity Chart
• Based on the example discussed previously, a velocity graph shows the amount of
effort that the Scrum team has reported as complete for each sprint of the 4 Sprints
completed:
Effort Estimations
• It is important that all items in the Scrum Product Backlog are
estimated using the same base for estimation.
• If story points are used all teams have to agree on the same metric and
a common scale to use.
• If Component Teams are used it is important that members of all
teams participate in the estimation to ensure that all efforts are
covered.
Behaviour Driven Development(BDD)
• Behaviour Driven Development (BDD) is a software development process
that originally emerged from Test Driven Development (TDD).
• Its focus on
• Providing a shared process and shared tools promoting communication
to the software developers, business analysts and stakeholders to
collaborate on software development, with the aim of delivering product
with business value.
• What a system should do and not on how it should be implemented.
• Providing better readability and visibility.
• Verifying not only the working of the software but also that it meets the
customer’s expectations.
Continue
• Behaviour Driven Development −
• Derives examples of different expected behaviours of the system.
• Enables writing the examples in a language using the business
domain terms to ensure easy understanding by everyone
involved in the development including the customers.
• Gets the examples ratified with customer from time to time by
means of conversations.
• Focuses on the customer requirements (examples) throughout
the development.
• Uses examples as acceptance tests.
Continue
• BDD (Behaviour Driven Development) is a methodology for
developing software through continuous example-
based communication between developers, QAs and BAs.
• Purpose of BDD methodology is to encourage communication amongst
the stakeholders of the project so that the context of each feature is
correctly understood by all members of the team (i.e. shared
understanding), before development work starts.
• Helps in identifying key scenarios for each story.
BDD Practices
• Specification by Example (SbE) :
• Use the examples in conversations to illustrate the business rules and the
behaviour of the software to be built.
• How does this thing will help? Ans: to eliminate common misunderstandings
about the business requirements.
• Test Driven Development (TDD):

• The developers use these specifications as a guide to implement increments of new
functionality.
• Results in a lean codebase and a suite of automated regression tests that keep the
maintenance costs low throughout the lifetime of the software.
Gherkin in BDD
• In BDD, Examples are called Scenarios.
• Scenarios are structured around the Context-Action-Outcome pattern
and are written in a special format called Gherkin.
• The scenarios are a way of explaining (in plain english) how a given
feature should behave in different situations or with different input
parameters.
• Because Gherkin is structural, it serves both as a specification and
input into automated tests, hence the name “Executable
Specifications”.
What is a feature file and what does it contain
• Feature files are text files with .feature extension.
• can be opened by any text editor as well as readable by any BDD-aware
tool, such as Cucumber, JBehave or Behat.
• Feature files should start with the context of the feature (which is
essentially the story), followed by at least one scenario in the following
format
• Feature: Some terse yet descriptive text of what is desired
• Scenario: Some determinable business situation
• Example
Example of Feature file
• Feature:
• In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
• Scenario:
• Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
• Scenarios in feature files should focus on the “what” rather than the “how”.
The scenarios should be concise and to the point, so that the reader can
quickly grasp the intent of the test without having to read a lot of irrelevant
steps.
Why should we write feature files
• The aim of the feature files is to document the scenarios talked
through in order to give an indication of how much work is involved in
delivering the feature.
• The feature files are also the drivers for the automated tests.
• Feature files also serve as a definition of done (DoD), meaning that
when all the scenarios have been implemented and tested successfully,
we can mark the story as done.
Who should write feature files
• It doesn’t really matter who actually writes/types the feature files, it
could be any member of the delivery team, however, the contents
(scenarios) which are discussed by a trio of Dev-QA-BA are the
essential part of feature files.
• Getting the shared common understanding of the feature is the key
element.
When should feature files be written
• Feature files should be written during the story grooming sessions
where the details of each story is discussed.
• Feature files containing scenarios should be written before
development starts so that developers as well as QA have a clear
understanding of the intent of the story.
• There should be a shared understanding of the story. The scenarios
serve as requirements to development.
Where should feature files be kept
• There should be one source of truth serving both as specification and
automated execution, therefore should be kept somewhere where every
member of the team has easy access.
• Having said that, because the feature files are the drivers of the automated
tests, they should ideally be kept in source control system (GitHub) so that
any updates to the feature files is immediately reflected on to the tests.
• For non-technical members who have no experience with Git, we can always
execute a dry-run of the feature files which will then output the list of all
existing scenarios without actually exercising the feature files.
How should we write feature files
• Two ways of writing feature files
• Imperative
• Declarative
• Imperative style of writing a feature file, is very verbose, contains low

level details and too much information.
• Pros and Cons
• Declarative style of writing a feature file is concise and to the point,
contains only relevant information about the story.
• Pros
Example
• Feature: Serve coffee
• In order to earn money
• Customers should be able to
• buy coffee at all times
• Scenario: Buy last coffee

• Given there are 1 coffees left in the machine
• And I have deposited 1 dollar
• When I press the coffee button
• Then I should be served a coffee
Example
• Feature: Account Holder withdraws cash
• Scenario: Account has sufficient funds

• Given the account balance is $100
• And the card is valid
• And the machine contains enough money
• When the Account Holder requests $20
• Then the ATM should dispense $20
• And the account balance should be $80
• And the card should be returned
Example
• Title: Customer withdraws subway ticket
• As a customer
I want to withdraw subway ticket from the machine,
so that I don’t have to wait in line at the ticket office.
• So how do we know when we have delivered this story?

• There are several scenarios to consider: the machine must have tickets,
the customer must provide payment, the customer must provide trip
details. Of course, there will be other scenarios.
continue
• Scenario 1: Machine has tickets
Given the machine has tickets
And the customer provides trip details
And the customer provides an acceptable form of payment
When the customer requests the ticket
Then ensure the ticket is dispensed
And ensure the payment is debited
And ensure the ticket works
Continue
• Scenario 2: Machine is out of tickets
Given the machine is out of tickets
And the customer provides trip details
And the customer provides an acceptable form of payment
When the customer requests the ticket
Then ensure an out of tickets message is displayed
And ensure the payment is not debited
Testing
• 2 Approach
• Test-Last
• Test-Early
Test-Last Approach
• With this approach, as testing has to wait till the particular stage is completed
• Unit testing, that is supposed to be done by the developers is often skipped. The
various reasons found are based on the mind-set of the developers.
• This results in −
• Compromising on the quality of the product delivered.
• Having the accountability for quality on testers only.
• High-costs in fixing the defects, post delivery.
• Inability to obtain customer satisfaction, which would also mean
loss of repeat business, thus effecting credibility.
Test-First Approach
• The Test-First approach replaces the inside-out (write code and then
test) to outside-in (write test and then code) way of development.
• In these methodologies, the developer designs and writes the Unit tests
for a code module before writing a single line of the code module.
• The developer then creates the code module with the goal of passing
the Unit test.
TDD Process Steps
Advantage of TDD
• The developer needs to understand first, what the desired result should be
and how to test it before creating the code.
• Testing and refactoring before the developer moves on to the next test.
• As the suite of Unit tests is run after each refactoring, feedback that each
component is still working is constant.
• The Unit tests act as living documentation that is always up to the data.
• If a defect is found, the developer creates a test to reveal that defect and
then modify the code so that the test passes and the defect is fixed. This
reduces the debugging time. All the other tests are also run and when they
pass, it ensures that the existing functionality is not broken.
Continue
• The developer can make design decisions and refactor at any time and
the running of the tests ensures that the system is still working. This
makes the software maintainable.
• The developer has the confidence to make any change since if the
change impacts any existing functionality, the same is revealed by
running the tests and the defects can be fixed immediately.
• On each successive test run, all the previous defect fixes are also
verified and the repetition of same defect is reduced.
• As most of the testing is done during the development itself, the
testing before delivery is shortened.
Misconception
• TDD is all about testing and test automation.
• TDD does not involve any design.
• TDD is only at Unit level.
• TDD cannot be used by traditional testing projects.
• TDD is a tool.
• TDD means handing Acceptance tests to the developers.
Acceptance Criteria
• Acceptance Criteria are conditions which a software application should
satisfy to be accepted by a user or customer.
• It mentions the defined standards of a software product must meet.
• These are a set of rules which cover the system behaviour and from
which we can make acceptance scenarios.
• It include
• Functional
• Non-functional
• Performance
Example of Acceptance Criteria
• User Story: Creation of orders in online shopping cart
• Criteria: 1.
• User should be able to selects multiple items and add to shopping cart.
• The user should be able to see the items in the shopping cart.
• The user should be able to purchase items using their local currency.
• The user should be able to see an order number when the payment method is made.
• Other examples of Acceptance Criteria can include:

• The user would not be able to submit a form if all the mandatory fields are not entered.
• Modes of payments can be selected, like payment by credit card, debit card.
• An automatic email is sent once the payment is made and confirmed.
Acceptance Test
• It is a formal test conducted to determine whether the software
application satisfies its Acceptance Criteria and also help the customers
to decide whether to accept the system or not.
• The customer implements the acceptance tests to check whether the
user story is completed and correctly implemented.
• An application can have many acceptance tests to be sure that the
functionality of software works.
• These are black box approach tests.
Example
• The customer screen allows user to perform search on first and last
names
• Add few customer names in the database.
• Display customer search button
• Enter the name to be searched.
• Hit Search button.
• Expected results should be displayed
Acceptance Criteria Acceptance Testing
1. Set of conditions which need to be met to
1. Scenarios derived from acceptance criteria.
accept story as complete
2. Acceptance Criteria requires minimal amount
2. Here we require detailed documentation.
of documentation
3. It is a created prior to development phase, in 3. It is implemented during the development
planning phase. phase.
4. It states what needs to be done 4. It states how it needs to be done.
5. Acceptance criteria is written by the product
5. Acceptance tests can be added anytime by the
owner or the business analyst before the
customers or a specific testing team.
development phase.
6. Definition of acceptance criteria is more 6. It is more easier for the stakeholder to explain
difficult for a stakeholder than acceptance tests the acceptance scenario than criteria
7. It ensures that the team knows when they are 7. It ensures that the system is behaving as
completed with the user story. expected.
8. It is made through joint effort of developers, 8. Here it is implemented by developers and
testers and stakeholders. testers.
Acceptance TDD
• Acceptance Test Driven Development (ATDD) defines Acceptance
Criteria and Acceptance Tests during the creation of User Stories, early
in development.
• The Key practices in ATDD are as follows −
• Discuss real-world scenarios to build a shared understanding of the
domain.
• Use those scenarios to arrive at acceptance criteria.
• Automate Acceptance tests.
• Focus the development on those tests.
• Use the tests as a live specification to facilitate change.
Benefits of ATDD
• Requirements are unambiguous and without functional gaps.
• Others understand the special cases that the developers foresee.
• The Acceptance tests guide the development.
TDD vs BDD
• TDD describes how the software works.
• On the other hand, BDD −
• Describes how the end user uses the software.
• Fosters collaboration and communication.
• Emphasizes on examples of behaviour of the System.
• Aims at the executable specifications derived from the examples
Principle of Agile Testing
• Testing is NOT a Phase
• Testing Moves the project Forward
• Everyone Tests
• Shortening Feedback Response Time
• Clean Code
• Reduce Test Documentation
• Test Driven
Exploratory testing
• Exploratory Testing is defined as simultaneous learning, test design and test
execution.
• It is an approach to testing that values the tester as an integral part of the test
process and shares the same values as the Agile Manifesto.
• Exploratory Testing is also complementary to test automation; that is while
automated checks are checking for regression issues, Exploratory Testing focuses
on new features which have been developed.
• The exploratory testers focus on areas where existing automated tests might
come up short.
• Testing can be unstructured and freestyle or be managed using charters and test
sessions.
• Also due to the short intervals of development, testing inherently becomes risk
based, and exploratory testing can focus on high risk areas to find potential
problems.
Brian Marick’s testing quadrant
Continue
Continuous
• Quadrant Q1 − Unit Level, Technology Facing, and supports the developers.
Unit tests belong to this Quadrant. These tests can be Automated tests.
• Quadrant Q2 − System level, business facing, and conform product behaviour.
Functional tests belong to this quadrant. These tests are either manual or
automated.
• Quadrant Q3 − System or User Acceptance Level, Business Facing and focus
on real time scenarios. User Acceptance Tests belong to this quadrant. These
tests are manual.
• Quadrant Q4 − System or Operational Acceptance Level, Technology Facing
and Focus on Performance, Load, Stress, Maintainability, Scalability Tests.
Special tools can be used for these tests along with automation testing.
Risk based Testing
• Risk is the occurrence of an uncertain event with a positive or negative effect
on the measurable success criteria of a project.
• It could be events that have occurred in the past or current events or
something that could happen in the future
• These uncertain events can have an impact on the cost, business, technical
and quality targets of a project.
• Positive and Negative Risks
• Risk based testing involves prioritizing the feature's, modules and functions
to be tested based on impact and likelihood of failures.
• It involves assessing the risk based on the complexity, business criticality,
usage frequency, visible areas, defect prone areas, etc.
When to implement Risk based Testing
• Risk based testing can be implemented in
• Projects having time, resource, budget constraints, etc.
• Projects where risk based analysis can be used to detect
vulnerabilities to SQL injection attacks.
• Security Testing in Cloud Computing Environments.
• New projects with high risk factors like Lack of experience
with the technologies used, Lack of business domain
knowledge.
• Incremental and iterative models, etc.
Risk Management Process
• Factors for the Practice
Likelihood Impact
Complexity Business Importance
New Development (level of reuse) Financial Damage
Interfacing Usage intensity
Size External visibility
Technology Cost of rework
Inexperience (development team)
Regression Testing
• Regression testing essentially checks if the previous functionality of
the application is working coherently and that the new changes
executed have not introduced new bugs into the application.
• In the agile environment, Regression Testing is performed under two
broad categories:
• Sprint level Regression testing: This regression test is focused on
testing the new functionalities that are implemented since the last
release.
• End to End Regression testing: This test incorporates end-to-end
testing of ‘all’ the core functionalities of the product.
Regression testing approaches
• The Traditional Testing Approach: In this method, each sprint cycle
is followed by sprint level regression test. Post a few successful sprint
cycles, the application goes through one round of end-to-end
regression testing.
• This method allows the team to focus on the functional validity of the
application and gives testers the flexibility to decide on the degree of
automation they want to implement.
Continue
• Delayed Week Approach: In this approach, the sprint level regression test
is not confined to a timeline and can spill over into the next week. For
example, if the sprint level regression test that is supposed to be completed
in Week 2 is not completed, then it can spill over to Week 3.
• This approach works well in the beginning of the testing cycles as the testing
team at that time is still in the process of gaining an implicit understanding
of the functionalities and the possible defects.
• Instead of parking the bugs/defects and addressing them at a later date,
continuous testing lifts the burden of backlogs that build up during end-to-
end regression tests.
Continue
• Delayed Sprint Approach: In this approach, the regression cycle is
common and regression test cases that were employed for the second
sprint contain the functionality stories that were a part of the first
sprint.
• Since the regression cycle is only delayed by a sprint, this approach
discounts the need for having two separate regression test cycle types.
This approach also avoids a longer end-to-end regression test cycle.
• this approach has two challenges –
• Maintaining the sanctity of the regression tests is difficult.
• Maintenance of automation efforts increases considerably.
Agile Architect
• The architect is responsible for defining and maintaining the structure
of the solution, and ensuring that it will meet the requirements.
• An agile architect must also help the team to work together in an agile
fashion, to jointly own the solution, and to interface well with other
parts of the organisation.
• Five points
Continue
• Understanding the requirements - identifying the stakeholders, helping to
analyse the requirements and extracting those of architectural significance
• Formulating the design - creating a solution structure which will meet the
various requirements, balancing the goals and constraints on the solution,
• Communicating the architecture - making sure that everyone understands the
architecture. Different people have different viewpoints, so the architect has to
present various views of the system appropriate to different audiences,
• Supporting the developers – making sure that the developers are able to realise
the architecture, by a combination of mentoring and direct involvement,
• Verifying the implementation – ensuring the delivered system is consistent with
the agreed architecture, and will meet the requirements.
Principles for the Agile Architect
• Value People
• Communicate
• Less is More
• Embrace Change: Plan It, Manage It
• Choose the Right Solution for the Enterprise
• Deliver Quality
• Model and Document in an Agile Fashion
Principles
• Single Responsibility Principle
• Open Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principles
• Dependency Inversion Principle
Single Responsibility Principle
• A class should have one and only one reason to change, meaning that a
class should have only one job.
• Example:
• consider a module that compiles and prints a report. Imagine such a
module can be changed for two reasons.
• First, the content of the report could change.
• Second, the format of the report could change.
• It would be a bad design to couple two things that change for different
reasons at different times.
Continue
• public class UserSettingService
public void changeEmail(User user)
if(checkAccess(user))
//Grant option to change
public boolean checkAccess(User user)
//Verify if the user is valid.
}
Continue
• public class UserSettingService }
{ public class SecurityService
public void changeEmail(User user) {
{ public static boolean checkAccess(User
user)
if(SecurityService.checkAccess(user))
{
{
//check the access.
//Grant option to change
}
}
}
}
Open Closed Principle
• Objects or entities should be open for extension, but closed for modification.
• A module will be said to be open if it is still available for extension. For
example, it should be possible to add fields to the data structures it contains,
or new elements to the set of functions it performs.
• A module will be said to be closed if it is available for use by other modules.
This assumes that the module has been given a well-defined, stable
description (the interface in the sense of information hiding).
• A class is closed, since it may be compiled, stored in a library, baselined,
and used by client classes. But it is also open, since any new class may use
it as parent, adding new features. When a descendant class is defined, there
is no need to change the original or to disturb its clients.
Example
• public class AreaCalculator
public double Area(Rectangle[] shapes)
double area = 0;
foreach (var shape in shapes)
area += shape.Width*shape.Height;
return area;
}
Continue
• public double Area(object[] shapes) • }
• { • else
• double area = 0; • {
• foreach (var shape in shapes) • Circle circle = (Circle)shape;
• { • area += circle.Radius * circle.Radius
* Math.PI;
• if (shape is Rectangle)
• }
• {
• }
• Rectangle rectangle = (Rectangle)
shape; • return area;
• area += • }
rectangle.Width*rectangle.Height;
• public abstract class Shape }
{ }
public abstract double Area(); public class Circle : Shape
} {
public double Radius { get; set; }
public class Rectangle : Shape public override double Area()
{ {
public double Width { get; set; } return Radius*Radius*Math.PI;
public double Height { get; set; } }
public override double Area() }
{
return Width*Height;
Liskov Substitution Principle
• Let q(x) be a property provable about objects of x of type T.
Then q(y) should be provable for objects y of type S where S is a
subtype of T.
• The idea here is that the subtypes must be replaceable for the super
type references without affecting the program execution.
• If the subtype is not replaceable for the supertype reference, then in
order to support the subtype instances as well we go ahead and make
changes to the existing code and add the support. This is a clear
violation of OCP.
Example
• class Bird { List<Bird> birdList = new ArrayList<Bird>();
public void fly(){} birdList.add(new Bird());
public void eat(){} birdList.add(new Crow());
} birdList.add(new Ostrich());
class Crow extends Bird {} letTheBirdsFly ( birdList );
class Ostrich extends Bird{ }
fly(){ static void letTheBirdsFly ( List<Bird> birdList ){
throw new UnsupportedOperationException(); for ( Bird b : birdList ) {
} b.fly();
} }
}
public BirdTest{ }
public static void main(String[] args){
Example
• class Bird{
public void eat(){}
}
class FlightBird extends Bird{
public void fly()()
}
class NonFlight extends Bird{}
Interface Segregation Principles
• A client should never be forced to implement an interface that it
doesn’t use or clients shouldn’t be forced to depend on methods they
do not use.
• ISP splits interfaces that are very large into smaller and more specific
ones so that clients will only have to know about the methods that are
of interest to them.
Example
Continue
Dependency Inversion Principle
• Entities must depend on abstractions not on concretions. It states that
the high level module must not depend on the low level module, but
they should depend on abstractions.
Example
Example

7 Distributed Agile

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 Distributed Agile

Uploaded by

Copyright:

Available Formats

Agile Software Development

B.TECH SEMESTER 6TH CSE

• Product backlog Properties

• Product backlog Properties

• The best way to visualize this product backlog is with a treemap.

• Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of

• In the following slide a simple treemap of a two-story house is demonstrated:

• The best way to visualize this product backlog is with a treemap.

• Treemaps were invented in the 1990s by Dr. Ben Shneiderman as a way of

• In the following slide a simple treemap of a two-story house is demonstrated:

• What Is (User) Story Mapping?

• What’s the Purpose of Story Mapping?

• What agile values and principles does story mapping support?

• Who Created Story Mapping?

• Why Use Story Mapping?

• What (Other) Benefits Do You Get Out of Story Mapping?

• What (Other) Benefits Do You Get Out of Story Mapping?

• Not keeping the map visible

• Managers don’t make decisions for the team

• To create a Release Plan the following things have to be available

Velocity is the number of story points completed by a team in an iteration.

𝑇𝑜𝑡𝑎𝑙 𝑆𝑡𝑜𝑟𝑦 𝑝𝑜𝑖𝑛𝑡𝑠

• Here velocity = 105.6 Story points/Sprint

• What influences velocity?

• Are used to represent “work done”.

• X-Axis: time (usually in days)

• Depicts the total Sprint Backlog hours remaining per day

• Will the release be done on right time?

• Consists of bars (one for each sprint)

• Consists of bars (one for each sprint)

• Issues/Challenges involved in implementing SCRUM in distributed

• This can lead to misunderstandings, delays, and mistakes.

• In large Scrum projects, it can be challenging to coordinate the work of multiple

• In distributed and large Scrum projects, integrating different components and

• This requires close collaboration between different teams, as well as careful

• When working with distributed teams, it's important to be sensitive to cultural

• Overall, successfully managing a distributed and large Scrum project

• It also requires a willingness to adapt and iterate the process as needed to

• How can issues involved in Distributes and Large SCRUM projects be

• Key points to consider:

• Establish clear communication channels:

• Key points to consider:

• Key points to consider:

• Break the project down into smaller chunks:

• Key points to consider:

• Use Scrum ceremonies/events properly:

• Scrum ceremonies such as daily stand-up meetings, sprint planning meetings,

• Key points to consider:

• Emphasize team building:

• In distributed and large projects, team building can be challenging, but it is

• Key points to consider:

• Assign clear roles and responsibilities:

• Key points to consider:

• Assign clear roles and responsibilities:

• Key points to consider:

• Emphasize continuous improvement:

• It is an indication of the average amount of Product Backlog turned into an

• Test Driven Development (TDD):

• Imperative style of writing a feature file, is very verbose, contains low

• Scenario: Buy last coffee

• Scenario: Account has sufficient funds

• So how do we know when we have delivered this story?

• Other examples of Acceptance Criteria can include:

public void changeEmail(User user)