カテゴリー 全て - journey - deliverables

によって Alex Ostreiko 9か月前.

167

Sprint Planning

Effective sprint planning involves a clear understanding of the goals, deliverables, and activities for the upcoming sprint. It emphasizes the importance of quality assurance at the start of work on bugs or user stories, minimizing hand-offs, and ensuring more user stories are fully completed rather than partially done.

Sprint Planning

Sprint Planning

details

Why Small Batches?
when we make commitments/predictions, we place a bet that we can honour the commitments

if there is a way to prove that our bet was solid and that it will pay off, we should do it

therefore we should endeavour to prove as quickly as possible, to strengthen our conviction...

debrief

2 parts

what if
try and delay assigning owners to WIs
understanding of how
PO

steps back

task out

swarming: use breakout rooms

hmm, think more on that

go over the same WIs, create tasks?

potentially estimate tasks in ideal hours

WBS activities

what are the different activities that we need to work through to complete each WI

avoid cookie-cutter stage names

checklist is fine

advanced teams

understanding of what
this part is over when

we have a candidate

team thinks there is enough work for the Sprint

SM plays devil's advocate

encourage team to ask questions

PO presents work

do not overcommit

undercommitting is preferrable

everyone necessary to make the decision about the team's needs and capabilities should be present

potentially other stakeholders

team goes over every single item

READY or actionable state

prioritized, ordered Product Backlog

what else will happen in the next two weeks?

something besides the work items in ADO
Dev Team Learning

Postman

Skills Radar Learning decisions/commitments

e.g.

workshops

LLs

KTs

Goals

priorities
complete the high priority work items first

even at the expense of not completing lower priority work items

everyone helps

this will happen if we own the SG

we have to care about and we will care about something we co-created

what are our intended results?
sense of purpose
Goals in Scrum
Product, Sprint, US
Sprint Goal will help to
maximize the value of the work produced

we can work very hard and still not produce something valuable

imagine a ship that is moving very fast but in circles

align and focus the team
Who owns the Sprint Goal?
it is your goal
Why is this Sprint valuable to the Stakeholders, and how will they validate that they received something valuable?
What is the outcome and the impact that we want to make in the next 2 weeks?

we want to maximize the impact

note that it is possible to work very hard, and not make any impact

What is trying to happen?
where is tension?

Note

we have been completing Planning without dwelling too much on the how part
but it is important because

there are two distinct parts to Sprint Planning: the what and the how

and understanding how the work will be executed to complete the work items

keep in mind that, this is most important

the plan is not the goal. the goal is the goal

the plan can change to better accommodate the goal

we might even have to adjust the what with the better understanding of the how

understanding the work items

The Scrum Guide suggests limiting Planning for 2-week at 4 hours
we have been completing these meetings in 2 hours
unlike some other meetings, here
we will make a commitment to achieve a goal by adopting a course of action to be carried out by the Team

this value of such commitment will become even more pronounced when we will begin working with our new partner

by making them wait

either via

just being late

buggy software

insufficient communication

inflexible architecture

use priority field?

the commitment is that the team will prioritize certain items

this means that with the exceptions of emergencies

helping with a priority item is more important than starting on a new non-priority item

we prioritize the list of work items that we commit to deliver

we set the expectations for the rest of the org

we need to be predictable so that other stakeholders can make plans

we will make decisions

these decisions will often have impact on the whole company

language matters because it can communicate intent
manifest your creative intent through the application of your will

we are magicians

making dreams a reality
setting and achieving goals
planning

Intro

What if
Let's reserve some time to talk about today's plan as well
How
We'll do this the usual way

what/how

What
deliverables and activities

what do we bring for the journey?

We'll discover the goal or theme

map of the jungle

Why
We are here to plan our next Sprint

for the next 2 weeks we are going on a journey

We are going on a Journey in a Jeep through the Jungle

Journey-Jeep-Jungle

Journey: Work Execution

how we accomplish movement of Jeep through Jungle

Jungle: Work Flow

shaped as Work Load

the Sprint Backlog?

Jeep: our Work Process

it is in our Span of Control

check-in

colour describing the team
what do you need to make this meeting successful?
for you
how would you like this meeting to be?
what would make this meeting good?
play Apollo 13 "finest hour" video
what positive advances you expect this Sprint?
< 30 seconds
not a discussion
atmosphere we want: friendly, playful, yet generative and useful
remember our DTA
ask questions

start

rapport
for effective group decision making

would help to build and maintain rapport

communicate that you are listening and paying attention

you are not in school where the teacher lectures students in a one-way manner

we are a dynamic, emergent, adaptive system

rapport, effective communication is our oxygen

if you have to do other work

use the law of two feet

don't normalize disengagement

look at the speaker, nod, gesticulate, say "uhuh" etc.

like if we had a face-to-face meeting

such as Planning

a relationship of mutual understanding or trust and agreement between people
Agile/Lean secret
OODA loop

PDCA

Heart of Agile

Collaborate, Deliver, Reflect, Improve

empathy for the next step

who will be using what we make (the code we write)?

other developers refactoring or optimizing the code

including yourself

other departments

students

understand the needs and problems of the people at the next step in the pipeline

requirements cannot fully encapsulate the needs of cusomers

it is important to know the context as well

thin knowledge vs thick knowledge

what is the difference between thin knowledge and thick knowledge

Consider if you are cleaning a table

is it to put storage boxes, or is it to prep for a medical procedure?

Thick knowledge is also knowing why

understand the priorities

Thin knowledge is knowing how

trust and safety allows us to

drop the armour

unleash the potential of people

be more authentic in our communications

ultimately results in better performance

mindset: care about each other's success

that's why Agile is tough: you can't force care, trust, and respect--you have to create conditions for it to grow

invite it to happen

and that, in turn, will bring hyper productive performance

imagine how safe you would feel, knowing that everyone on the team is rooting for your success

a team at a sports game: you want them to win

unlike in school

where students get their assignments

only concerned with their grades

notes

considerations
When you are starting work on your Bug or User Story

always think about QA

make notes to suggest the procedure

Can some parts be QAd while you are still working?
minimize the hand-offs wall

show penny game

stop starting and start finishing
Solving half of the problems is better than creating half-solved problems

better to have 80% of User Stories 100% done than 100% User Stories 80% done

relay race vs marathon

we need to pass the baton to the other teams in the org every Sprint