Agile scrum mythbusters

Topics to cover Starting with.. Done!
Agile Myths
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Learning board

● ScrumMaster draws the burn-down & burn-up charts
○ No. ScrumMaster is a facilitator. Everybody owns the Burndown chart and Scrum Master may help the
team in drawing it if needed
● Product Owner and Scrum Master can be same person
○ Never do that. That is disaster. It’s a conflict of interest for both the parties. Product Owner tends to
be demanding role and Scrum Master is neutral who helps the team to push back demands more
than they could commit
Agile Myths
● Only those could be a Scrum Master who are certified in this role
○ Well it’s funny to hear such points. Anybody who has a trait to help others, believes in openness,
motivates the team and passionate to facilitate and move the team towards the desired goal faster and
quicker could be a good Scrum Master. Scrum Master ensures that the team become self-organizing,
adaptable to change, highly performing and always focused towards delivering the better version of
product in short intervals of time. Even a 8 year old kid can be a better scrum master than a 55 years
experienced professional

● Daily stand-ups running more than 15 min
○ The whole idea is to have a quick connect and that’s why it is named standup
○ Everyone quickly updates on what they have done last day, what’s their plan for today and if they have
any blockers they can talk about that
○ We do not do technical discussions. You need to flag it and park it for the stand-up to over. Then
whoever is interested would join your conversation
● ScrumMaster takes the updates in the daily standup meetings
○ Well if this is how you are doing then you are not doing it appropriately at all.
○ Daily standup is a team meeting where ultimate goal is to find out how much work remained to
achieve the goal of the sprint and do the replan to move toward it
Agile Myths
● User stories are requirement documents
○ User stories are one liners written in the end user’s perspective
○ here is a value that a story talks about and that is something we deliver
○ User stories are not requirement documents but they could help you in writing the document very
effectively if you want

● Agile says no documentation
○ Well this is very much misunderstood
○ Agile says no comprehensive documentation as time to know everything is high which is actually impossible
to know upfront, then time to write everything is high, time to read everything is high and so on
○ Documentation is LIVE here. It is always getting updated as we incrementally grow towards the end goal
○ Agile emphasis more on conversation and confirming the understanding by clearly written acceptance
criteria against each story
Agile Myths
● Awards based on agile audits
○ Well it is very debatable topic. Audit happens against set parameters and guidelines. Agile is a continuous
journey where one team who is highly performing could get stuck in very next sprint or there may be some
reason which could turn down their agility
○ Failure is OK and in agile we believe in failing faster which I believe the audit reports may not like
○ Ofcorse there could be practices and parameters that could help you in knowing Agility Health of your team or
organization but they should help team to introspect and find their own answers which they could then vote
and decide to improve. It could happen every quarter or month but absolutely not a stricter way and should
respect the anonymity if ever conducted

● We can only do scrum but not Kanban Or Kanban but not XP or something like that
○ Well, our focus is to BE AGILE. Scrum, Kanban ,XP are different approaches which has practices that helps us in
becoming agile. So, we choose which practice we could use, which one we couldn’t and something that you use now
may not be needed tomorrow or maybe you create your own version
○ I have seen teams practicing Scrum and have visual boards and define WIP limits which are Kanban practices and also
do TDD, CI, Refactoring and often play planning poker to estimate stories and tasks. Now, these are all XP practices
which they may not be even aware of but believe in it
Agile Myths
● We CAN NOT DO AGILE because...
○ Agile is a mindset that helps us in creating a culture. Now there could be many reasons where you feel you could not
agile like
■ We are Production Support team, we are not creating software, we are just 2-3 people team, We do not have roles
like scrum in our team, Yada Yada Yada
○ Knowingly unknowingly we all are agile and that may not be quoted into approaches or different practices but we are
handling changes in many ways. You need to tailor your process, the way you want to be, the degree of change you could
bring in and needless to use the terms and jargons that others are using
○ Be a smart agile carpenter where Scrum, Kanban, XP, Lean ,DSDM and many others are different tools in your box. You
may choose any tool you want in whatever combination that works for you and if it doesn’t you make your own but just
DO NOT GET STUCK. FAIL FASTER and CREATE SUSTAINABLE solutions.

Sprint Planning
● We can have it in 3 sections:
○ Section A: Discuss on ‘WHAT?’ - 1.5 hours
■ Product Owner (PO) sharing the goals of the sprint, work that need to be finished to achieve the goals
(stories, tasks, features, prod defects etc)
■ Development team (DT) clarifies the requirement by asking questions and we call come up to mutual
consensus on scope
■ Participants: PO, DT, PM, Architect, Leads, SM/Coach
○ Section B: Discuss on ‘HOW? & HOW MUCH?’ - 2-3 hours
■ Development Team identifies the capacity - how much could we commit?
■ Breaks big items into smaller items & record all queries
■ Estimate the work items
■ Draft the commitment based on estimate and capacity
■ Participants: DT, Leads, Architect, PM, SM/Coach
○ Section C: ‘Commitment’ 1.5 hours
■ Scrum Team agrees on commitment post clarifying their queries
■ Start the sprint in JIRA
■ Participants: PO, DT, PM, Architect, Leads, SM/Coach

Quiz
1. In the first half of sprint planning, the team asks questions to Product Owner to clarify what is to be built.
2. While estimating product backlog items size in sprint planning is technically allowed, it’s best to estimate prior
to planning.
3. The product owner assigns development tasks to the team.
4. The product owner is involved in figuring out how code is written.
5. In the second half of sprint planning, the product owner may be needed to help further clarify questions the
team has.
6. The second half of sprint planning is for the team to break product backlog items down into development tasks.
7. Development tasks can be estimated in hours.
8. Instead of estimating tasks in hours, some teams find it easier to count up the # of tasks for a given sprint. They
then use that number for their sprint Burndown.
9. Sprint planning for a 2 week sprint should be time boxed to 4 hours.
10. Adding a backlog refinement session half way through your sprint can help with making sprint planning shorter
and more effective.

Daily Standup
● Co-located Product Owners need to participate almost everyday
● Distributed Product Owners may need to respect the convenience of the development
team while they can expect the summary of updates from Scrum Master
● It may go beyond 15 min. Its Ok. Still try to flag technical discussion and park them for
later
● Scrum Master may need to call out names to structure the conversation
○ We may go person by person or story by story
● Since physical board will not be used, hence we need to keep the JIRA board up-to-date
○ It is everyone’s shared responsibility
○ Any misleading or incorrect information needs to flagged and immediately corrected
● JIRA screen must be shared at the start of the session
● Ensure the zoom/ bluejeans link is added in invite

Quiz
1. It’s fine for the daily scrum to last up to 45 minutes.
2. People from outside the team may attend, provided it’s okay with the team and they don’t interfere.
3. The daily scrum is one of the 3 important inspects and adapt loops in scrum.
4. The daily scrum is sometimes referred to as the “Stand-up” or “Daily Standup”
5. The 3 questions answered in daily scrum are:
a. What did you do since our last scrum?
b. What do you plan to do until our next scrum?
c. Do you have any impediments?
6. Discussions of how to resolve issues should be done during a sidebar after the daily scrum.
7. Teams usually don’t benefit from this daily sync up.
8. It’s helpful for the daily scrum to be in the same location, at the same time every day.
9. Managers should attend the daily scrum to help ensure everyone is doing enough work.
10. The Daily Scrum shouldn’t start until all participants arrive.

Sprint Review
● It happens at the end of the sprint and it needs to be prepared well
● We need to do a pre-review event, a day before the Review meeting where the intent is to
enable development team to prepare well for the review meeting and check if the
experience is getting affected due to poor connection, infrastructure setup, if any pre-
recorded video is needed
● Incase the multiple team members are presenting then how are we going to orchestrate
the experience when all of us are distributed?
● We can not have just one person who is recording the feedbacks and almost
everyone need to attempt to collect the feedback as there may be call drops or poor
audio connectivity
● Post Sprint Review, the Scrum team need to have a meeting to collate all the review
feedbacks

Quiz
1. It’s expected that a team will demo a feature even if they didn’t finish it in the sprint.
2. The product owner accepts a feature based on the conversations and acceptance criteria that was previously
discussed with the team, not by some criteria the team hasn’t known before.
3. Stakeholders are welcome at the review as long as they don’t interfere. Their feedback can be helpful for
shaping the product moving forward.
4. Teams should spend at least 4 hours preparing for the review, and the review should include powerpoint slides.
5. If the team can’t demo a feature because it wasn’t completed, it’s okay for a manager to question the team’s
approach in this meeting.
6. The sprint review is mainly for show and has little impact on the product.
7. A manager should pick who does the demos during the sprint review.
8. Feedback from stakeholders during the sprint review should be collected and put on the backlog for
consideration by the product owner instead of spawning long conversations during the review.
9. Most sprint reviews last only 10 minutes.
10. The scrum master should be in charge of running the sprint review and making sure the team demos what they
need to demo.

Sprint Retrospective
● We need to focus on video conferencing
● Will be great if we all come prepared with points to discuss
● We should ensure that all gets chance to speak
● Focus should be more on learning how we are doing and identifying few points that we can
improve upon to enhance our experience
● Participants: Scrum Team only
● The summary of the meeting could be shared with all (also on confluence)

Quiz
1. Anyone who wants to attend should be able to show up.
2. The retrospective is confidential. Whatever happens in the retrospective stays in the retrospective, unless the
team agrees to share it.
3. The purpose of the retrospective is tell people what they did wrong during the last sprint.
4. Your scrum master should use the same exercise for the retrospective every time for consistency.
5. The retrospective is one of the 3 important inspect and adapt loops in scrum
6. Trust is essential for a good retrospective.
7. A sprint retrospective is optional for a highly performing team.
8. Retrospectives can benefit from snacks.
9. The scrum master should always be the one to facilitate the Retrospective.
10. No one but the team members should ever be invited to the retrospective.

Backlog Refinement
● It usually happens in the mid-sprint where the Product Owner educates development team
about future work and want to keep transparency on any changes in backlog. We need to
revisit the backlog based on our experience so far as we want to achieve the product goal
over finishing planned work items
● Participants: PO, DT, PM, Architect, Leads, SM/Coach
● This event can also happen in many sections:
○ Section A: PO shares the information with team, collects the queries and respond if
possible - 1.5 hours
○ Section B: PO responds to pending queries and check the possibility of spike and
confidence of team to deliver the work in future sprints - 1.5 hours

THANK YOU
www.Benzne.com
Anuj M Ojha

Agile scrum mythbusters

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Agile scrum mythbusters

Similar to Agile scrum mythbusters (20)

More from Tarun Singh

More from Tarun Singh (15)

Recently uploaded

Recently uploaded (20)

Agile scrum mythbusters