The document outlines a comprehensive guide to agile project management, discussing key principles, methodologies, and practices such as the agile manifesto, user stories, and iterative delivery. It emphasizes the importance of collaboration, customer satisfaction, and adaptability in delivering high-value software through frameworks like Scrum and Kanban. Additionally, it covers the roles of Scrum Master and Product Owner, the dynamics of cross-functional teams, and strategies for transitioning from traditional waterfall to agile processes.

1. Test Strategy

2. Contents:
1. Agile foundation
2. Agile Framework
3. Transitioning from Waterfall to Agile Project
Management
4. Planning with Agile User Stories
5. Agile at Work: Agile Meetings

3. Agile Foundations

4. Agile
● Agile is a software development methodology to build a software incrementally
using short iterations of 1 to 3 weeks so that the development process is aligned
with the changing business needs.
● Instead of a single-pass development of 6 to 18 months where all the
requirements and risks are predicted upfront, Agile adopts a process of frequent
feedback where a workable product is delivered after 1 to 4 week iteration.

6. Having the agile mindset
Agile manifesto: Values
We are uncovering better ways of developing software by doing it and helping others
do it. Through this work, we have come to value −
● Individuals and interactions over Processes and tools
● Working software over Comprehensive documentation
● Customer collaboration over Contract negotiation
● Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left
more.

7. 12 Principles of Agile Manifesto
1. Customer Satisfaction
Highest priority is given to satisfy the requirements of customers through early and
continuous delivery of valuable software.
1. Welcome Change
Changes are inevitable during software development. Ever-changing
requirements should be welcome, even late in the development phase. Agile
processes should work to increase customers' competitive advantage.

8. 3. Deliver a Working Software
Deliver a working software frequently, ranging from a few weeks to a few months,
considering shorter time-scale.
4. Collaboration
Business people and developers must work together during the entire life of a
project.
5. Motivation
Projects should be built around motivated individuals. Provide an environment to
support individual team members and trust them so as to make them feel

9. responsible to get the job done.
6. Face-to-face Conversation
Face-to-face conversation is the most efficient and effective method of conveying
information to and within a development team.
7. Measure the Progress as per the Working Software
Working software is the key and it should be the primary measure of progress.
8. Maintain Constant Pace
Agile processes aim towards sustainable development. The business, the
developers, and the users should be able to maintain a constant pace with the
project.

10. 9. Monitoring
Pay regular attention to technical excellence and good design to enhance agility.
10. Simplicity
Keep things simple and use simple terms to measure the work that is not
completed.
11. Self-organized Teams
An agile team should be self-organized and should not depend heavily on other
teams because the best architectures, requirements, and designs emerge from
self-organized teams.

11. 12. Review the Work Regularly
Review the work done at regular intervals so that the team can reflect on how to
become more effective and adjust its behavior accordingly.

12. The cost of multi tasking
Think of your own experience. Maybe you were writing an office memo, and then
suddenly got an email from your supervisor, so you stop writing the memo, and you
start reading the email. You reply to email and then go back to your memo, you
probably have to take few moments to review where you have left off. And once you
start writing you got an another email you switch task again.
● Each time you switch between tasks, you have to do a little bit of thinking to get
back on track.
● The transition period for your brain to go from one task to the next is called
context switching.
Individuals and interactions

13. ● Research who studied this found that if you try to multitask with three or more
tasks at the same time, you're spending much more time context switching than
finishing the work.
● Agile mindset is to try and limit your team's multitasking.
● Instead of working on several different things at once, the entire team will focus on
a limited set of high value tasks. This team can then complete the high value work.
This helps with one of Agile's guiding principles, continuous delivery in short
iterations.

14. Avoid work hand-offs
One practice that you'll see in almost every workplace is handing off tasks to different
people. This is typically called handoffs for short. What usually happens is that you
finish your work and then hand it off to someone else.
Ex: A software developer might finish some code and then hand it off to a tester to
test the code.
A lot of time gets wasted waiting for someone else to finish their work. One of the
challenges with handoffs is it encourages large batches of work to go through the
system.

15. The penny game

17. Deliver at a predictable pace
● Breaking down the work into smaller batches.
● Typically, an agile team will write user stories to represent this batch of work.
● Then at the beginning of each sprint, the team will commit to delivering a few of
those batches. This is often called the sprint goal.
● Most agile teams will deliver the work product in a short iteration that's typically
called a sprint. A sprint is usually two weeks long.
● The reason that most agile teams deliver in sprints is that it's a very well-
structured way to deliver products quickly.

18. Cross-functional teams
Every agile team should be a self-sufficient team with 5 to 9 team members and an
average experience ranging from of 6 to 10 years. Typically, an agile team comprises
of 3 to 4 developers, 1 tester, 1 technical lead, 1 product owner and 1 scrum master.
Product Owner and Scrum master are considered to be a part of Team Interface,
whereas other members are part of Technical Interface.

20. User story
A user story is a requirement which defines what is required by the user as
functionality. A user story can be in two forms −
● As a <User Role> I want <Functionality> so that <Business Value>
● In order to <Business value> as a <User Role> I want <Functionality>
During release planning, a rough estimate is given to a user story using relative scale
as points. During iteration planning, the story is broken down into tasks.

21. Deliver working software
Start with highest value
● This works mainly on the Pareto principle. 80% of the effects comes from 20% of
the causes.

22. Start with the highest value

23. Avoid PowerPoint software
● We should always focus on delivering working software to customers.
● To do that, you need to deliver small, fully-functional features of the product to the
customer in iterations or sprints.
● We just want a web form that captures the customer's contact information and
stores it in a database.
● For the first milestone, you need to create the database. Then you might need to
develop the software that connects the form to the database. Finally, you have to
create the form that captures the information. You might also need extra code to
make sure that you have the correct data in the forms.
● So in a Agile development, for the 1st sprint we can build a form having name and
email fields, and user can save these to database - so this is a working software.

24. Respond to change
Inspect and Adopt
Now, imagine we went back to our web application that collects our customer contact
information. The webpage relies on a web server, It also runs an operating system that
might change frequently, It also relies on a database which is always changing. Plus,
your customer might be using different web browsers and operating systems.
● That's why agile teams work with shorter periods of time and embrace frequent
changes.
● If they didn't make frequent changes, then chances are when they finish the
project, their software would already be obsolete.

25. Stay within timeboxes
● Timebox is a like a box of time that can't expand. Say you have meeting
scheduled for 45 min, then the meeting will end in 45 min, and whatever the team
decides within the timebox will be final outcome.
● Each person on an agile team has their own personal timebox. They shouldn't
work more than eight hours a day.
● If team members start putting in overtime or working over the weekends, then it
can interfere with the team's predictability.

26. Jump off the waterfall
● It's just that instead of working on these things in sequential phases, you'll have
the whole team working on these things all at the same time, within a sprint in
Think of an agile team as accomplishing
many of the same things as you do in
waterfall, but they're just doing it in a
cross-functional way and compressing all
the phases into a few weeks.

27. Commit to sprint
● Agile teams will deliver in a short iteration that's typically called a Sprint.

28. Sprint planning meeting
● First day of sprint
● Planning all sprint work
● Less than 2 hr meeting
● Every morning the Scrum team should stand up for it's daily Scrum. This is a 15
minute meeting where the team coordinates their work. This is primarily a meeting
between the different developers about the progress they're making on the
product.
Sprint review
● Customer feedback
● Less than 2 hr

29. ● The last hour and a half of the Sprint is dedicated to a team retrospective. This is
when the team reflects on how they can work better together.
Iterative delivery
● Agile teams focus on delivering the product incrementally and iteratively.
● Iterative delivery is a process on its own, but you can really think of it more as
refinement. The team is improving on the product at the end of every sprint.
● Software delivered to the customer at the end of each sprint should be a working
software which adds up the value for the customers business problem.

30. Popular Agile Frameworks
1. Scrum
● Scrum is the most popular agile framework, with 66 percent of all agile frameworks
being scrum or scrum variants.
● It helps software development companies handle large projects in small iterative
phases called “sprints.” These are time-boxed events where the development
team completes a series of tasks within a larger project.
● Key ideas behind scrum
● Roles: Scrum divides the team into three primary roles—product owner,
scrum master and the development team.
● Events: Scrum events include sprint planning, daily scrum, sprint review and
sprint retrospective. Teams use these events to execute projects and refine
the process.

31. ● Artifacts: Scrum artifacts include the product backlog, sprint backlog and
increment. Collectively, these allow teams to prioritize tasks and deliver
projects within agreed timelines.
2. Kanban
● As an agile framework, kanban is a work management method that doesn’t follow
a top-down, instruction-giving approach. Instead, members use a pull system that
divides tasks into simple workflows (i.e., “to be done,” “in progress” or “done”).
● This makes it easy for members to identify and work on the most important tasks
as well as efficiently manage their time and improve production.

32. Key ideas behind kanban
● Visualization: Kanban boards can visualize the different kinds of tasks that
teams need to perform in a project. You can either use sticky notes on physical
whiteboards or kanban tools to map digital cards (representing tasks) on online
dashboards.
● Work in progress (WIP) limits: These are the number of in-progress tasks that
need to be completed before you can add new tasks. It’s the kanban technique
to discourage multitasking by allowing employees to focus solely on key tasks.
● Workflow: Tasks in the kanban method move along different stages until they’re
completed. Having clearly defined stages, known as the project workflow, helps
teams identify bottlenecks that diminish efficiency and cause project delays.

33. Improve Customer Collaboration
Common roles on the team
Scrum master
● A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so
that they can meet their commitments
● Responsibilities of a scrum master:
○ To enable close co-operation between all roles and functions.
○ To remove any blocks.
○ To shield the team from any disturbances.
○ To work with the organization to track the progress and processes of the company.
○ To ensure that Agile Inspect & Adapt processes are leveraged properly which includes :
[Daily stand-ups, Planned meetings, Demo, Review, Retrospective Meetings, and, To facilitate team
meetings and decision-making process.]

34. Product Owner
A Product Owner is the one who drives the product from business perspective. The
responsibilities or a Product Owner are as follows −
● To define the requirements and prioritize their values.
● To determine the release date and contents.
● To take an active role in iteration planning and release planning meetings.
● To ensure that team is working on the most valued requirement.
● To represent the voice of the customer.
● To accept the user stories that meet the definition of done and defined acceptance
criteria.

35. Combat groupthink
● Groupthink is when a few experts make a convincing argument and the rest of the
team just follow along, something like Sam says it a good idea, so it must be right.
● An Agile team should avoid groupthink because everyone should be able to ask
challenging questions about the product.
● On an Agile team, if you can't simply explain your thinking to someone else, then
it's probably not a well-designed solution.
● So, the team should always be having these face-to-face meetings where
everyone's contributing their ideas and asking challenging questions. It's a key
part of being a self-organized team.

36. Planning poker

37. Transitioning from
Waterfall to Agile Project
Management

38. Starting your agile practice
Team Capacity
● Capacity is how much availability the team has for the sprint. This may vary
based on team members being on vacation, ill, etc.
● Team Capacity is a product of the total number of Scrum team members
multiplied by the number of team productive days.
Individual Capacity:
● Plan each person’s workload individually rather than planning workloads by team.
● This will help you better accommodate always changing project requirements
while also maintaining your team’s sanity.
● A core agile team of designer, developer, and product manager working equal
time on a project may sound nice, but it’s not practical in reality if you have
multiple projects going on at once.

39. Transitioning Clients to an Agile Process
Discovery: Start with conducting a solid discovery process that incorporates agile
methodologies. This will get them used to working collaboratively.
Check-Ins: Use ongoing communication to break down formalities and kickstart the
collaborative process. Collaborative project management tools, regular calls, and
holding sprint demos in person can help with this.
Uncertainty: Help your clients understand the value of embracing uncertainty and
continuous learning while also being clear with them about expectations around
timing, budgets, etc. Features they think they want in the beginning might be re- or de-
prioritized during ongoing user tests. And that’s okay.

40. Estimating:
● A key part of successful sprint planning is estimating task difficulty.
● Start first by using hours as your scale of difficulty (i.e. how many hours will
something take), then move into rating difficulty on a scale of 1-10. Hardcore agile
practitioners use a more complicated scoring process based on the Fibonacci
scale. This will help build team consensus on how to execute each sprint’s
required deliverables.
Sprint length:
● Sprints are typically two weeks long, but this may not work for your team’s
capacity or the project they’re on. Consider adjusting sprint lengths as necessary
until you find something that works for all project stakeholders.

41. Agile at Work: Building
Your Agile Team

42. Make sure you are ready
Establishing why agile is needed
● List out what wrong things are going on in the project to motivate the organization
to move forward to Agile.
● Challenges may include:
○ Poor/missing requirements
○ Manager compensate/fills in the missing part after the project starts
○ Project having unrealistic deadlines
○ Project having changing priority
○ Poor stakeholder communication
○ Lack of quality assurance
Once everybody agrees that there are problems that need to be fixed, then you can
start on the path of your agile transformation.

43. Getting management agreement
● Present the solution for the problems you face in your project
● Recommend that the executive sponsor from the small team of agile, as its better
to go small than large.
● Remember that Agile is an organizational change, so work hard to carefully set
expectations and prepare the executives for a long transformation process.

44. Forming the team
1. Cross functional team
Every agile team should be a self-sufficient team with 5 to 9 team members and
an average experience ranging from of 6 to 10 years.
1. Scrum master
A Scrum Master is a team leader and facilitator who helps the team members to
follow agile practices so that they can meet their commitments.
1. Product owner
A Product Owner is the one who drives the product from business perspective.

45. Letting the team self organize
● The self-organized team takes on a lot of that responsibility that was previously
left to the project managers.
● Self organizing the teams
○ Responsible for the deliverables
○ Make the schedule
○ Improve own performance
What does a project manager do in agile?
● Translating agile process for traditionally minded executives
● Protecting the team from sliding back into the traditional project management.

46. Establishing an Agile Mindset
Working as an agile team
Five core values are
● Communication
You see this emphasis on communication with the shared workspace, user
stories, pair programming, collective code ownership, and daily stand-ups.
The team has a dedicated scrum master who's job it is to notice when people
aren't communicating.
● Simplicity
The output should be the simplest solution for the job. Over-engineering can be a
big problem in software development. The team should do the simplest thing that
could possible work.

47. ● Feedback
This is the core value is a subset of communication.
The team needs to give feedback to each other. The product owner should give
feedback to the team. The team should collaborate with the product owner and
make changes. There should always be someone giving you feedback, or getting
feedback from you.
● Courage
It takes courage to communicate and accept feedback. They also need the
courage to improve work in code. Agile teams build and improve products a little
at a time. That means that the small solution created earlier might have to be
thrown away and improved. This is called software refactoring, and it is a
continuous effort by the team.

48. ● Respect
For the team to work well, the team needs to share their knowledge and respect
their coworkers. They need to accept that there's no one superhero, and the entire
team deserves respect.
Delivering like an agile
● According to Pareto principle only 20% of the software features and functions are
most often used.
● If only 20% of your effort is giving you 80% of your value, then the product owner
has a responsibility to deliver that value first.
● The team starts work on what the product owner ranks highest and not what's
easiest for the team to deliver.

49. Planning with Agile User
Stories

50. Agile - Iteration Planning
● An Agile team works in iterations to deliver user stories where each iteration is of
10 to 15 days.
● Each user story is planned based on its backlog prioritization and size.
● The team uses its capacity − how many hours are available with team to work on
tasks − to decide how much scope they have to plan.
● The purpose of iteration planning is for the team to complete the set of top-ranked
product backlog items. This commitment is time boxed based on the length of
iteration and team velocity.
● Scrum master, Product owner and Agile team are involved in the meeting.

51. Prerequisites of Planning
● Items in product backlog are sized and have a relative story point assigned.
● Ranking has been given to portfolio items by the product owner.
● Acceptance criteria has been clearly stated for each portfolio item.
Planning Process
● Determine how many stories can fit in an iteration.
● Break these stories into tasks and assign each task to their owners.
● Each task is given estimates in hours.
● These estimates help team members to check how many task hours each
member have for the iteration.
● Team members are assigned tasks considering their velocity or capacity so that
they are not overburdened.

52. Planning Steps
● Product Owner describes the highest ranked item of product backlog.
● Team describes the tasks required to complete the item.
● Team members own the tasks.
● Team members estimate the time to finish each task.
● These steps are repeated for all the items in the iteration.
● If any individual is overloaded with tasks, then his/her task is distributed among
other team members.

53. Agile - Release Planning
● The purpose of release planning is to create a plan to deliver an increment to the
product.
● Scrum master, Product owner, Agile team, and Stakeholders are involved
Prerequisites of Planning
● A ranked product backlog, managed by the Product Owner. Generally five to ten
features are taken which the product owner feels that can be included in a release
● Team's input about capabilities, known velocity or about any technical challenge
● Market and Business objective
● Acknowledgement whether new product backlog items are needed

54. Planning Data
The list of data required to do release planning is as follows −
● Previous iterations or release planning results
● Feedback from various stakeholders on product, market conditions, and deadlines
● Action plans of previous releases / iterations
● Features or defects to be considered
● Velocity from previous releases/ estimates.
● Organizational and personal calendars

55. Agile at Work:
Agile Meetings

56. Scrum meeting
The purpose of your agile scrum meeting is to set yourself and your team up for the
day’s work ahead. Ideally, you’re having these meetings each morning, and you’ll
want to keep them as quick as possible – that’s why we recommend doing them
literally standing up.
● Frequency: Daily
● Meeting length: 10 minutes (max)
● Agenda template:
○ Blockers (2 minutes)
○ What did you do yesterday? (3 minutes)
○ What are your goals for today? (3 minutes)
○ How close are we to hitting our sprint goals? Comfort level? (2 minutes)

57. Expert tip:
Have this meeting in-person whenever possible. Being able to ask questions in real
time helps tremendously in removing blockers.
Sprint planning meeting
The goal of the sprint planning meeting is for the scrum master (or manager) to leave
knowing who is doing what – and the team to leave understanding the work that’s
required. This type of agile meeting isn’t intended for new projects or ideations, it’s
more for clarification on existing work.

58. ● Frequency: Sprintly (bi-weekly)
● Meeting length: 60 minutes
● Agenda template:
○ What wasn’t completed last sprint? (5-10 minutes)
○ Discuss Deliverables, agree on effort and assign each ticket (40 minutes)
○ Any other issues/concerns? (5-10 minutes)
● Expert tips:
○ When assigning tickets, make sure you communicate expectations for the
work to be done. (You want to ensure that everyone totally understands what
“done” means!)

59. ○ This is the meeting to cover off the little things (but big in terms of
productivity!) that are coming up, like holidays, vacation time and other
interruptions.
Sprint retro meeting
Your retrospective meeting is all about identifying what went well – and what didn’t –
throughout the sprint, and using this information to improve your next sprint.
● Frequency: Sprintly (bi-weekly)
● Meeting length: 60 minutes

60. ● Agenda template:
○ Demo (20-30 minutes)
○ Product acceptance and change requests (10 minutes)
○ What prevented you from doing your best work? What should we start, stop,
edit, keep? (5-15 minutes)
○ Demo day prep: Who wants to run it? What do we demo? Who deserves a
shout-out? (5 minutes)

61. ● Expert tip:
Try not to let the “What prevented you from doing your best work?” agenda item
monopolize the conversation. You can avoid this by having a place for your team to
share issues and add comments throughout the sprint, when they’re top of mind
(psst…SoapBox does that!). This keeps the conversation during the meeting quick,
and focused on making decisions rather than sharing context.

62. Backlog grooming meeting
our backlog is a list of all upcoming features and things to be done by the team.
Backlog grooming meetings are intended to keep your backlogs up-to-date and ready
to be pulled from for upcoming sprints.
● Frequency: Sprintly (bi-weekly)
● Meeting length: 30 minutes
● Agenda template:
○ What wasn’t completed last sprint that needs to be completed? (5 minutes)
○ What came up that ne
○ eds to be fixed? (10 minutes)
○ What needs to get done to move our product forward? What’s the highest
priority? (10 minutes)

63. ○ What’s something that could come down the pipeline that would disrupt
everything? (5 minutes)
● Expert tip:
Keep your project management tool (we use Jira) open while you’re running this
meeting. Use it to look at new bugs, issues and technical debt to help facilitate the
meeting.

64. Reporting with Agile
Charts and Boards

65. Product Backlog
● Product backlog is a list of everything that needs to be done to create the product
- features, defect fixes and other technical work.
● It mainly contains User stories, Bugs, and Improvements.
● The product owner has the sole authority to add or change the work to the
backlog.Then the list gets reprioritized based on the changes.
● DEEP: A way to remember agenda
● D - Detailed
○ The highest value user stories should be well understood, so they can be
completed in the next sprint.
○ Distance stories can be described with less detail.

66. ● E - Estimated :
○ The stories should be estimated, the product backlog is more than just a list
of work. It's also a planning tool. Again, place the highest priority stories at
the top. Stories further down can get a rougher estimate.
● E - Emergent:
○ A backlog is not static, it will change over time. As the team learns more
about the product, new user stories will be added, removed, or changed.
● P - Prioritized
○ The backlog should be prioritized. The backlog should be sorted with the
highest value items at the top. The least valuable should be at the bottom.

68. Task Board
A task board is a tool used by individuals, teams or organizations to represent work
and its path towards completion. This includes tasks that are in progress, finished
tasks and upcoming tasks that may be in a backlog.

69. Advantages of task board:
● Promotes team interaction and discussion – Throughout the day you will see
teammates, stakeholders and members of other teams stop by the board for
discussion. This increases greatly if the board is located near the team and highly
visible
● Visibility – Anyone walking buy can make a quick second assessment on where
the team is in the iteration. No cards left for a row? That story is complete. No
white cards left, just green cards? Only testing remains. Lots of pink cards? Lots of
defects.

70. ● Good for new teams to visualize Scrum – By having this tangible thing in front
of them that they can touch, makes it easier for new Scrum teams to understand
the process
● Support full team commitment – Now the whole team sees all of the tasks daily
and keeps them from just focusing on “their” tasks. When using task tracking tools
it is too easy to just create a view of “my tasks” and then tune out the rest.

71. Burndown Chart
● A burndown chart is a graphical representation of work left to do versus time.
● A burndown chart is almost a “must” because of main reasons:
● monitoring the project scope creep
● Keeping the team running on schedule
● Comparing the planned work against the team progression

73. Agile Retrospective
● Retrospective meetings are intended to reflect on the most recent
sprint/project/milestone and identify areas that need improvement and celebrate
team wins.
● Retrospective meetings can be scheduled towards the closing days of a sprint
and before the next sprint is started to reflect on the most recent sprint
● Provide a safe space for the team to reflect on and discuss what works well (and
what doesn't!) so you can improve.

74. Step - 1 Set the stage (5 min)
● Welcome everyone to the retrospective meeting
● Embrace a positive spirit of continuous improvement and share whatever you
think will help the team improve.
● Don't make it personal, don't take it personally.
● Listen with an open mind, and remember that everyone's experience is valid
(even those you don't share).
● Set the boundary of your discussion – is it that last sprint? the last quarter? since
the project started? Be clear how far back you're going to go.
● Encourage the team to embrace an improvement mindset, away from blame.

75. Step - 2 What went well ? (10 min)
● Start the session on a positive note. Have each team member use green
sticky notes to write down what they feel went well (one idea per sticky). As
people post their stickies on the whiteboard, the facilitator should group
similar or duplicate ideas together.
● Discuss your ideas briefly as a team.

76. Step - 3 What needs improvement ? (10 min)
Same structure as above, but using pink or red stickies. Remind your team that this is
about actions and outcomes – not about specific people.
Step - 4 Next steps (5 min)
● Having identified what didn't go so well, what concrete actions can the team take
to improve those things? Have your team use blue sticky notes to place ideas on
the board. Group them and then discuss as a team, agree to which actions you
will take, assign owners and a due date to get them DONE.
● Thank everyone for their involvement and their honesty. Quickly run through the
list of follow-up items, their owners and due dates.

77. Questions?
Thank you