#Fundamental understanding of agile - By SN Panigrahi,
Essenpee Business Solutions,
What is Agile Methodology,
Project Life Cycle, Predictive Life Cycle, Iterative Life Cycle,
Incremental Life Cycle, Adaptive Life Cycle, Agile Life Cycle,
Waterfall Method, Sprint, Product Backlog, Sprint Planning, Sprint Backlog, User Stories, Daily Scrum, Sprint Review, Sprint Retrospective, Product Owner, Sprint Team, Scrum Master, Agile Scope, Agile Schedule, Burnt down Chart, Kanban, Lean, Ceremonies
2. 2
SN Panigrahi is a Versatile Practitioner, Strategist, Energetic Coach, Learning Enabler & Public Speaker.
He is a Business Consultant, International-Corporate Trainer, Mentor & Author
He has diverse experience of over 30 Yrs and expertise in Project
Management, Contract Management, Supply Chain Management,
Procurement, Strategic Sourcing, Global Sourcing, Logistics, Exports &
Imports, Indirect Taxes – GST etc.
He had done more than 200 Workshops Globally on above
Published more than 500 Articles; More than 90 Youtube Presentations &
90 SlideShares
He is an Engineer + MBA +PGD ISO 9000 / TQM with around 30 Yrs of Experience
He is a certified PMP® from PMI (USA) and become PMI India Champion in 2016
Authorized Training Partner (ATP) Instructor Issued by Project
Management Institute (USA)
Also a Certified Lean Six Sigma Black Belt from Exemplar Global & KPMG
Have been Trained in COD for 31/2 Yrs. on Strategy & Leadership
GST Certified – MSME – Tech. Dev. Centre (Govt of India)
ZED Consultant – Certified by QCI – MSME (Govt of India)
Member Board of Studies, IIMM
Co-Chairman, Indirect Tax Committee, FTAPCCI
Empanelled Faculty in NI MSME
He has shared his domain expertise in various forums as a speaker & presented a number of papers in various national and
international public forums and received a number of awards for his writings and contribution to business thoughts.
SN Panigrahi 9652571117
snpanigrahi1963@gmail.com
Hyderabad
3. 3
Agile Methodology is a people-focused, results-focused
approach to software development that respects our
rapidly changing world.
It’s centered around adaptive planning, self-
organization, and short delivery times.
AGILE methodology is a practice that
promotes continuous iteration of development and
testing throughout the software development lifecycle of
the project. Both development and testing activities are
concurrent unlike the Waterfall model.
It’s flexible, fast, and aims for continuous
improvements in quality, using tools
like Scrum and eXtreme Programming.
Agile PM Principles
Frequent Inspection &
Feedback
Transparent
Collaborative Approach Continuous Improvement
Self Organization
Changes are Widely
Accepted for
Improvements
Focus on Customer
Value
Iterative & Incremental
Delivery
Experimentation &
Adaptation
Flexible, Fast, Swift to
Changes
4. 4
The process of “plan, design, build, test, deliver,” works okay for making cars or
buildings but not as well for creating software systems. In a business environment
where hardware, demand, and competition are all swiftly-changing variables, agile
works by walking the fine line between too much process and not enough.
It abandons the risk of spending months or years on a process that ultimately
fails because of some small mistake in an early phase. It relies instead on
trusting employees and teams to work directly with customers to understand the
goals and provide solutions in a fast and incremental way.
,
5. 5
The agile methodology process adopts an ‘inspect and adapt’ approach to project
management. This greatly reduces costs and time. Since project teams work in agile
sprints, it allows stakeholders more opportunities to collaborate.
The continual adaptation for which the agile method allows for is essential in
uncertain and sometimes unstable environment or where scope is not very Clear @
the beginning.
Project team are empowered to re-plan instead of going ahead with a once-off
planned project, unadaptable to change that is bound to fail. This allows for increased
competitivity and preserves a project’s market relevance.
Regular feedback from the stakeholders and end-users of the project which means that the
project can be completed to suit the end-user in the best way possible.
Daily Agile Meetings held as part of the method help to determine issues and be prepared
for them well in advance.
,
6. 6
A project life cycle is the phases that a project passes through from its start to its completion. It
provides the basic framework for managing the project. PMBOK® ed 6
Within a project lifecycle, there is typically at least one phase related to developing the product,
service or result; also known as a development life cycle, of which there are several types:
The adaptive life cycle is also called a flexible or change-focused method (or agile
or change-driven methods) and it Combines both Incremental & Iterative Life Cycles
to Deliver Incremental Small Packages & Repeated take Iterations (Feedback) for
Continuous Improvements.
Scope, time, and cost are defined within the early phases of the project. Any changes must then
be carefully managed through Change Control Mechanism. Also known as waterfall life cycles.
The deliverable is produced through a series of iterations that successively add functionality within a
predetermined time frame - getting feedback on a regular basis. The deliverable are completed only after
the final iteration.
Small Incremental Deliveries Frequently. Each increment includes Analyse, Design,
Build &Test, Deliver. Each increment integrates additional parts of the solution until
the final increment, where the remaining parts of the solution are integrated.
7. Project and Development Life Cycles – Different types
Hybrid (Combination of Predictive (Waterfall) and Adaptive): Elements of the project that have fixed requirements
follow predictive approach, elements that are ‘Progressively Elaborated’ follow an adaptive (iterative) approach
7
,
9. 9
➢ Requirements dynamic, repeated until correct, single
delivery
➢ Develop the product through a series of repeated
cycles,
➢ Allows feedback on partial completed or unfinished
work to improve and modify deliverable.
➢ Works well when uncertainty is high, when project
incurs frequent changes and stakeholders have
different view of desiredAnalyze Design
Build
Test
Deliver
Analyze Design
Build
Test
Deliver
Incremental
Delivery - 1
Analyze Design
Build
Test
Deliver
Incremental
Delivery - 2
Analyze Design
Build
Test
Deliver
Incremental
Delivery - 3
Analyze Design
Build
Test
Deliver
Incremental
Delivery - n
❖ Requirements dynamic, performed once
for a given increment, frequent small
deliveries
❖ Provide finished deliverables which
customer can use immediately
,
10. 10
Agile and Waterfall model are two different methods for software
development process. Though they are different in their approach, both
methods are useful at times, depending on the requirement and the type
of the project.
Agile Model Waterfall Model
•Agile method proposes incremental and iterative approach to
software design
•Development of the software flows sequentially from start point
to end point.
•The agile process is broken into individual models that
designers work on
•The design process is not broken into an individual models
•The customer has early and frequent opportunities to look at
the product and make decision and changes to the project
•The customer can only see the product at the end of the
project
•Agile model is considered unstructured compared to the
waterfall model
•Waterfall model are more secure because they are so plan
oriented
•Small projects can be implemented very quickly. For large
projects, it is difficult to estimate the development time.
•All sorts of project can be estimated and completed.
•Error can be fixed in the middle of the project. •Only at the end, the whole product is tested. If the requirement
error is found or any changes have to be made, the project has
to start from the beginning
,
13. 13
❖ In agile lifecycle, high priority items from product backlog work in an iteration.
❖ In Agile / Adaptive environment, the scope is not understood at the beginning of the
project and it evolves during the project
❖ Processes in each iteration: collect requirements, define scope & create WBS,
validate scope & control scope.
❖ In predictive lifecycle, collect requirements, define scope & create WBS is done once
and later only in case of changes. Validate scope done for each deliverable/phase review
& control scope will be ongoing.
❖ Product backlog (product requirements, user stories) will be the current needs of an agile
project
,
14. 14
Considerations for agile/adaptive environments
➢ A Scope is not understood at the beginning
➢ Team spend less time to define and agree on scope at the beginning
➢ They spend more time to establish the processes for the ongoing discovery and
refinement of scope
➢ Agile methods build and review prototypes and release versions to refine the
requirements
➢ As a result, the scope is defined and redefined throughout the project
,
17. 17
Sprint literal meaning is a short race at full
speed. Accordingly, teams usually define a
short duration of a Sprint up to 1- 4 weeks.
Sprint is one Timeboxed Iteration of a
continuous development cycle. Within a
Sprint, planned amount of work has to be
completed by the team and made ready for
review.
,
18. 18
Agile methodology Sprint is a set of planning
and management techniques, derived from
software development and based on the
iterative and incremental execution of
activities, where the requirements and
solutions evolve according to the needs of
the project.
Processes in each iteration: collect requirements, define scope & create WBS,
validate scope & control scope.
Team collaboratively sets their target with Product Owner as “Sprint Goal” and plan
their work in “Sprint backlog”.
As soon race starts after planning session, team work together to complete planned
work effectively and make it ready for review by the end of that period.
,
19. , 19
By allowing teams to get Feedback and Revise deliverables after every agile methodology sprint, modifications and changes are
easily incorporated and the project can be steered in a new direction.
Sprints or iterations are
regular and consistent
which allow for a constant-
growth model which team
members follow.
At the end of each agile sprint
retrospective or iteration it is
required that the project team
deliver results in moving the
project along.
The continual revision of
every aspect of the project
allows for true optimization
and quality results.
In comparison to the waterfall method, project teams have more than one chance to get each
aspect of the project right. Incremental Deliverables & Continuous Iterations, dramatically
increases project success rate.
,
21. 21
Process flow of scrum testing is as follows:
➢ Each iteration of a scrum is known as Sprint
➢ Product backlog is a list where all details are entered to get the end-product
➢ During each Sprint, top user stories of Product backlog are selected and turned into
Sprint backlog
➢ Team works on the defined sprint backlog
➢ Team checks for the daily work
➢ At the end of the sprint, team delivers product functionality
,
22. 22
Product backlog (product requirements, user stories) will be the current
needs of an agile project
High level User Stories readiness in Product backlog is the prerequisite of
starting a Sprint Cycle. Sprint Analysis help Scrum Master and Product
Owner to know the progress of Sprint in a glance.
User Stories = High Level Requirements
During sprint planning at the beginning of each sprint, the scrum team
can use the product backlog priority to help decide whether a new
requirement should be part of the sprint. Lower-priority requirements stay in
the product backlog for future consideration.
,
23. 23
Prioritized Features
Desired by Customer
Review Product Backlog
Sprint Goal, Estimate
Goal, Commit to Sprint
Features Assigned to
Sprint – Estimated by
Team
Inspect &
Adapt
Demo
FeaturesWhat is
Done &
What
Not
Plan for
Today.
Discuss any
Obstacles
User Stories
Pla
n
Tes
t
,
24. 24
A user story is the smallest unit of work in
an agile framework. ... A user story is an informal,
general explanation of a software feature written from
the perspective of the end user or customer.
The purpose of a user story is to articulate how a
piece of work will deliver a particular value back to the
customer. ,
25. , 25
Epic Definition in Agile Scrum Methodology
An Epic can be defined as a big chunk of work that has one common objective. It could
be a feature, customer request or business requirement. In backlog, it is a placeholder for a
required feature with few lines of description. It tells compactly about final output of user
needs. In the beginning, it may not contain all the details that team needs to work on. These
details are defined in User Stories. An epic usually takes more than one sprint to
complete.
What is epic in agile methodology
The Basic unit of work defined in Scrum is User story. But very often, when Product
Owner writes a user story for a feature or against customer request, that looks simple in the
beginning. But, while covering all related work and scenarios, same user story expands so
much that it can not fit either in a week or a sprint time-frame. It is the time to consider this
big user story as epic and start slicing it in smaller user stories. This way, Agile teams get
better effort estimate and get smaller but concrete output in single sprint.
26. 26
➢ Sprint a meeting is held during which the sprint itself is planned.
➢ The customer and project team discuss the work that needs to be completed during the sprint.
➢ It is down to the project team to determine how much time they will need to complete certain amounts of work and up to the
customer on the type of work that needs to be completed.
➢ Every sprint duration is different and each one is determined by the Scrum Master who acts as the team’s facilitator.
➢ Sprint durations should be kept consistent after deciding on the first one. Generally, and on average a sprint lasts 30 days.
➢ During a sprint, the customer is expected to step back and allow space for the project team to work. Daily stand up meetings are
held to ponder the project’s progress and to make decisions and face challenges.
➢ When the agile methodology sprint comes to an end, the project team presents its completed work to the customer/project owner
and the project owner uses the initially established criteria against which to compare if the work has been a success or failure.
,
27. 27
Sprint
Planning
Daily Scrum Sprint Review
Sprint
Retrospective
Sprint Planning is the scrum
ceremony happens at the
beginning of a new sprint
designed to make sure the team is
prepared to get the right things
done every sprint.
User stories can be broken up
into smaller tasks & assigned
during sprint planning so that
everyone knows what they’re held
accountable to.
The Daily Scrum is the team’s
chance to get together, define a
plan for the day’s work, and
identify any blockers.
The Scrum Master is responsible
for clearing these roadblocks
This ceremony provides a frequent
opportunity for the team to get
together and communicate
individual progress toward the
sprint goal.
The Sprint Review is the
scrum ceremony where
all work completed
during the sprint can be
showcased the
stakeholders.
Actionable feedback
received during the Sprint
Review should be
converted into new
product backlog items for
later prioritization and
discussion.
Alternatively named the
Sprint Demo.
The Sprint Retrospective
is the final scrum
ceremony in the
sequence that allows the
team to look back on the
work that was just
completed and identify
items that could be
improved.
Some common questions
asked are:
What went well over the
last sprint?
What didn’t go so well?
What could we do
differently to improve?
28. 28
Scrum Team
Product
Owner
Development
Team
Scrum
Master
Scrum Master
Scrum Master ensures everyone follows the practices prescribed by Scrum.
•A Scrum Master is a facilitator and Servant Leader who encourages and
demands self-organization from the development team.
•A Scrum Master enables close cooperation across all roles and functions,
addresses resource issue and disobedience of scrum practices.
•A Scrum Master protects the team from external and internal distractions.
•A Scrum Master removes impediments so the team can focus on the work at
hand and follow scrum practices.
•A Scrum Master is not typically a manager or lead, but he is an influential
leader and coach who does not do direct command and control.
Product Owner
Product Owner in Agile is like a spokesperson for customer
and needs to represent them,
•A Product Owner owns the Product backlog and writes user
stories and acceptance criteria.
•A Product Owner is responsible for prioritizing the Product
Backlog is prioritized and decides the release date and the
content.
•A Product Owner accepts or rejects product backlog item.
•A Product Owner has the power to cancel the Sprint, if he thinks
the Sprint goal is redundant.
•A Product Owner is the one who is responsible for the Return on
Investment (ROI) of the product.
Development Team
The Development Team builds the product that the Product
Owner indicates: the application or website, for example. The Team
in Scrum is “cross-functional”
•The Development Team includes all the expertise necessary to
deliver the potentially shippable product each Sprint
•The Development Team is self-organizing, with a very high
degree of autonomy and accountability.
•The Development Team decides how many items to build in a
Sprint, and how best to accomplish that goal.
•The Development Team is a cross functional, small and self-
organizing team which owns the collective responsibility of
developing, testing and releasing the Product increment.
•The Development Team may not appoint any team lead since
decisions are taken collectively by the team.
Customer
,
30. 30
1.We first need to determine a Product Backlog (a list of product requirements in order of priority), which is the responsibility of the
Product Owner
2.The Scrum Team makes estimates and arrangements for the workload based on the Product Backlog list in Product Backlog
Refinement Meeting
3.With the Product Backlog list, we need to hold a Sprint Planning Meeting for defining the sprint goal of this iteration (the time period of
a Sprint is typically 1 to 4 weeks), then selected a list of user stories to form the Sprint Backlog for the coming sprint which could fulfill
the sprint goal.
4.Sprint Backlog is completed by the Scrum Team, each member is refined into smaller tasks according to the Sprint Backlog (the
workload of each task can be completed within a few days)
5.Within the Sprint, a Daily Scrum Meeting is required and each of the meetings is time-boxed in about 15 minutes. Everyone must
speak and face-to-face to interact with all members for reporting what you did yesterday, and commit what you want to accomplish
today, and you can ask questions related to impediment or problems that you can’t solve. Then, update your Sprint burn down Chart.
,
31. 31
6. To achieve daily integration, that is, every day must have a version that can be successfully compiled and can be demonstrated; many
people may not have used automated daily integration. If it passes, the unit test code is executed immediately. If all of them are passed, the
version is released.
7. When all the user stories are completed, that is, the Sprint Backlog is completed, it means that a Sprint is completed. At this time, we need to
conduct a Sprint Review Meeting (also known as a review meeting). The product owner and the customer must participate. Every member of
the Scrum Team will demonstrate to them the working software they have completed and this meeting is very important and must not be
cancelled.
8Finally, The Sprint Retrospective is held after the sprint review at the end of each sprint. During the retrospective, the team self-identifies
elements of the process that did or did not work during the sprint, along with potential solutions. Retrospectives typically last 90 minutes and
are there to help us incorporate continuous improvement into our team culture and into our Sprint cadence.
,
32. 32
Velocity in Agile is used to measure how much work (User Points) can be completed in each iteration or a single Sprint and is the
key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.
“Worked example:” 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.
Once this is measured based on a few sprints, the team can then predict how many user points they should plan to complete per sprint. This
ultimately reveals how many sprints it will take to complete a project, and helps the team to measure efficiency along the way.
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.
Velocity in Agile
33. 33
Iteration burndown
chart
• Tracks the work that remains to be completed in the iteration backlog
• Used to analyze the variance with respect to an ideal burndown
• A forecast trend line can be used to predict the likely variance at
iteration completion and take appropriate actions
SN Panigrahi, Essenpee Business Solutions, India
34. 34
Project scope is all the work involved in creating DELIVERABLES
Agile scope management is different from scope management in a traditional project.
Traditional project management treats changing requirements as a sign of failure in upfront
planning.
Agile projects, however, have variable scope so that project teams can Frequently and
incrementally on Continuous basis incorporate Changes, Learning and Feedback, and
Ultimately Create Better Outcomes or Deliverables.
The signers of the Agile Manifesto recognized that scope change is natural and
beneficial. Agile approaches specifically embrace change and use it to make better-
informed decisions and more useful products.
,
35. 35
Traditional Project Approaches
Project teams attempt to identify and document complete scope at the
beginning of the project, when the teams are the least informed about the
product.’
Agile Project Approach
The product owner gathers high-level requirements at the beginning of
the project, breaking down and further detailing requirements that are going
to be implemented in the immediate future. Requirements are gathered and
refined throughout the project as the team’s knowledge of customer
needs and project realities grows.
,
36. 36
Traditional Project Approaches
Project Managers View Change as Negative & Rigidly Control and Discourage Changes
after stakeholders sign off on requirements.
Agile Project Approach
Change Management is an Inherent Part of Agile Processes.
Organizations view change as a positive way to improve a product as the project
progresses.
You assess scope and have an opportunity to include new requirements with every
sprint.
The product owner determines the value and priority of new requirements and adds
those requirements to the product backlog.
,
37. 37
Traditional Project Approaches
The cost of change increases over time, while the ability to make changes decreases.
Agile Project Approach
You fix resources and schedule initially. New features with high priority don’t necessarily
cause budget or schedule slip; they simply push out the lowest-priority features.
Iterative development allows for changes with each new sprint.
The scrum team determines scope by considering which features directly support the product
vision, the release goal, and the sprint goal.
The development team creates the most valuable features first to guarantee their inclusion and
to ship those features as soon as possible.
,
38. 38
• In agile lifecycle, high priority items from product backlog work in an iteration.
• Processes in each iteration: collect requirements, define scope & create WBS,
validate scope & control scope.
• In predictive lifecycle, collect requirements, define scope & create WBS is done
once and later only in case of changes.
• Validate scope done for each deliverable / phase review & control scope will be
ongoing.
• Product backlog (product requirements, user stories) will be the current needs of
an agile project
,
39. 39
• A Scope is not understood at the beginning
• Team spend less time to define and agree on scope at the beginning
• They spend more time to establish the processes for the ongoing
discovery and refinement of scope
• As a result, the scope is defined and redefined throughout the
project ,
40. 40
The scope of an Agile project is defined by high level requirements, in the form of User Stories, scheduled in the
Release Plan. Detailed (or deep) requirements are still necessary but they are only created when they are needed – this is the focused
bit.
That means that in Agile Project Initiation, the Product Owner produces User Stories for the entire project, but only produces
supporting documentation for those User Stories scheduled into the first Timebox. During the first Timebox detailed supporting
documentation is produced for the User Stories in the second Timebox, etc.
Role of the Project Brief in Defining Scope
The Project Brief is a prerequisite for Agile Project Initiation. The Project Brief provides the context in which the User Stories are written.
Role of the Release Plan in Defining Scope
The Release Plan is the main deliverable from Agile Project Planning. It lists the User Stories that are in-scope and when they are
scheduled for development. By implication it also indicates what is out-of-scope.
,
41. 41
Project Scope Management
Predictive Adaptive or Agile
Defining Project deliverables At the beginning Over multiple iterations
Scope change Low (through PICC) High
Stakeholder engagement At the beginning / end Ongoing / continuous
Decomposed scope WBS Epics
Repeated processes Baselined at once Collect requirements
Define scope
Create WBS
(for each iteration)
Feedback on deliverables At the end of the phase / project At the end of iteration
Repeated processes Validate scope - At the end of the
phase / project
Control scope - (ongoing through PICC)
Validate scope
Control scope
(at the end of each iteration)
Reference scope document Approved Scope baseline (Project
scope statement, WBS and WBS
dictionary)
Backlogs
(product requirements and user
stories)
Responsible for prioritization Project Manager Product Owner
,
42. 42
Iterative scheduling with a backlog:
• A form of rolling wave planning for predictive / agile approach to
product development
• Requirements are documented in user stories, then prioritized,
refined prior to construction
• Product features are developed using time-boxed periods
• This approach is used to deliver the incremental value to the
customer
• Multiple teams can concurrently develop a large number of
features that have few interconnected dependencies
• It welcomes changes throughout the development life cycle
,
43. 43
On-demand scheduling:
• This approach typically used in Kanban system is based on the
theory-of-constraints and pull-based scheduling concepts of lean
manufacturing to limit a team’s work in progress in order to
balance demand against the team’s delivery throughput.
• It does not rely on a schedule that was developed previously for
the development of a product or its increment
• It pulls work from a backlog or intermediate queue of work to
be done immediately as resources become available
,
44. 44
About Kanban / Lean Manufacturing
Kanban is a method for visualizing the flow of work, in order to balance demand with
available capacity and spot bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to
finish.
Team members pull work as capacity permits, rather than work being pushed into the
process when requested. ,
45. 45
Lean manufacturing or lean production, often simply "lean",
is a systematic method for:
• Waste minimization ("Muda") within a manufacturing
system without sacrificing productivity.
• Waste created through unevenness in workloads ("Mura").
• Lean also takes into account waste created through
overburden ("Muri") and
•
,
46. 46
Iteration burndown
chart
• Tracks the work that remains to be completed in the iteration backlog
• Used to analyze the variance with respect to an ideal burndown
• A forecast trend line can be used to predict the likely variance at
iteration completion and take appropriate actions
,
47. 47
Agile Project Management Glossary
Agile terminology can be confusing. We have compiled a list of the most common agile terms you may come across, and their
definitions:
❖ Agile - a project management approach based on delivering requirements iteratively and incrementally throughout the life cycle.
❖ Agile development – an umbrella term specifically for iterative software development methodologies. Popular methods include
Scrum, Lean, DSDM and eXtreme Programming (XP).
❖ Agile Manifesto – describes the four principles of agile development: 1. Individuals and interactions over processes and tools. 2.
Working software over comprehensive documentation. 3. Customer collaboration over contract negotiation. 4. Responding to
change over following a plan.
❖ Backlog – prioritised work still to be completed (see Requirements).
❖ Burn down chart – used to monitor progress; shows work still to complete (the Backlog) versus total time.
❖ Cadence – the number of days or weeks in a Sprint or release; the length of the team’s development cycle.
❖ Ceremonies – meetings, often a daily planning meeting, that identify what has been done, what is to be done and the barriers to
success.
❖ DAD (disciplined agile delivery) – a process-decision framework.
,
48. 48
Agile Project Management Glossary
➢ Daily Scrum – stand-up team meeting. A plan, do, review daily session.
➢ DevOps (development/operations) – bridges the gap between agile teams and operational delivery to production.
➢ DSDM (dynamic systems development method) – agile development methodology, now changed to the ‘DSDM project
management framework’.
➢ Kanban – a method for managing work, with an emphasis on just-in-time delivery.
➢ Kanban board – a work and workflow visualisation tool which summarises the status, progress, and issues related to the work.
➢ Lean – a method of working focused on ‘eliminating waste’ by avoiding anything that does not produce value for the customer.
➢ LeSS (large-scale Scrum) – agile development method.
➢ RAD (rapid application development) – agile development method; enables developers to build solutions quickly by talking directly
to end users to meet business requirement.
➢ Requirements – are written as ‘stories’ that are collated into a prioritised list called the ‘Backlog’.
➢ SAFe (scaled agile framework enterprise) – agile methodology used for software development.
➢ Scaled agile – agile scaled up to large projects or programmes, for example by having multiple sub-projects, creating tranches of
projects, etc.
,
49. 49
Agile Project Management Glossary
➢ Scrum – agile methodology commonly used in software development, where regular team meetings review progress of a single
development phase (or Sprint).
➢ Scrum of scrums – a technique to operate Scrum at scale, for multiple teams working on the same product.
➢ Scrum master – the person who oversees the development process and who makes sure everyone adheres to an agreed way of
working.
➢ Sprints – a short development phase within a larger project defined by available time (‘timeboxes’) and resources.
➢ Sprint retrospective – a review of a Sprint providing lessons learned with the aim of promoting continuous improvement.
➢ Stories – see Requirements.
➢ Timeboxes – see Sprints.
➢ Velocity – a measure of work completed during a single development phase or Sprint.
➢ Waterfall – a sequential project management approach that seeks to capture detailed requirements upfront; the opposite to agile.
➢ XP (eXtreme Programming) – agile development methodology used in software development; allows programmers to decide the
scope of deliveries
,
50. , 50
Generally on an Agile project, who can provide the best estimation of the tasks?
a. Development Team
b. Product Owner
c. Scrum Master
d. Subject Matter Expert
Correct answer is A.
Since Development Team executes tasks so they are the closest to the technical
details of the project. They can best provide the estimation regarding size and
time required to complete the tasks.
51. , 51
Sara, an Agile Coach, was explaining the importance of Burn charts to the team. She
explained how burn charts can be useful in tracking down team’s performance. Which of the
following statements about burn charts is wrong?
a. Burndown chart goes down whereas Burnup chart goes up
b. Burndown chart shows remaining work whereas Burnup chart shows completed work
c. Burndown chart shows scope changes whereas Burnup chart doesn’t
d. Burndown chart doesn’t shows scope changes whereas Burnup chart shows it
Correct answer is C.
Burnup charts maps both total work and work completed. In case of scope changes, that work
is reflected in the total work.
52. , 52
You and your Agile project team are currently demonstrating a potentially shippable
product increment to you project stakeholders. What Agile meeting are you conducting?
A) Review Meeting
B) Daily Standup Meeting
C) Retrospective Meeting
D) Deliverables Meeting
Ans : A
At the end of each iteration, you and your project team will demonstrate a potentially
shippable product increment to your project stakeholders. This occurs during an
Iteration Review Meeting.
53. , 53
You are a Product Owner working on an agile software development project and you have
brought all the Scrum team members together for the first Iteration Planning meeting. You read
the user stories to the team, and they have provided estimates to complete these user stories.
You have promised to leave them alone during the iteration to get the work done and they have
agreed to complete the work 100% according to the definition of done. What is this an example
of?
A) Two-way communication
B) Reciprocal commitment
C) Bi-partisan agreement
D) Emotional intelligence
Ans : B
This is an example of Reciprocal Commitment, where the Agile project team commits to
delivering the specified functionality 100 % according the definition of done at the end of the
iteration, and the product owner, organization and customer agree not to change priorities during
the iteration and leave the team alone to "do the work".
54. , 54
Agile project management and product development uses several different types of documents
specific to each iteration, which are referred to as "artifacts". All of the following are Agile
iteration artifacts except:
A) Iteration Vision Statement
B) Iteration Backlog
C) Iteration Plan
D) Iteration Burnup Chart
Correct Answer: A
The four main artifacts used in Agile project management and product development are the
Iteration Plan, Iteration Backlog, Iteration Burndown Charts and Iteration Burnup Charts. The only
type of "vision statement" used as an artifact in Agile is the Product Vision Statement. The
"Iteration Vision Statement" is a completely fake term that we made up for this question.
55. , 55
One of the major tools and techniques used in Lean Software Development is value
stream mapping. What is the primary purpose of value stream mapping?
A) To improve business processes
B) To identify and eliminate waste
C) To ensure product quality
D) To increase customer value
Correct Answer: B
The single most important goal of using Value Stream Mapping is to identify and
eliminate waste.
56. , 56
Extreme Programming (XP) defines four basic activities that are performed during the software
development process. These include designing, coding, testing and ... ?
A)Collaborating
B) Leveling
C) Communicating
D) Listening
Correct Answer: D
The four basic activities of XP that are performed during the software development process are:
1) Listening to the customer to determine what they want and also to your fellow development team
members.
2) Designing the code based on your team's understanding of the requirements resulting from Listening
to the customer and your team.
3) Coding because the end product of the development effort is based on programming the code.
4) Testing the code that has been programmed to deliver the highest quality code as close to bug-free as
feasible.
57. , 57
Projects operating in agile environments where a high degree of uncertainty exists and where
the scope is not yet fully defined, may not benefit from detailed cost calculations due to frequent
changes. Instead, lightweight estimation methods can be used to generate a fast, high-level
forecast of project labor costs, which can then be easily adjusted as changes arise. Detailed
estimates are:
A. Reserved for short-term planning horizons in a just-in-time fashion.
B. Never developed in an agile project.
C. Only developed if the project stakeholders allow the project manager to do so.
D. Developed early during the project but are never updated due to frequent changes.
A - In agile/adaptive environments, detailed estimates are reserved for short-term planning
horizons in a just-in-time fashion. The rest of the choices are incorrect. [PMBOK 6th edition,
Page 234] [Project
Framework]
