Refinement + Planning - Agile Software DI C. Heumader

Refinement

Was	kontinuierliche Pflege und Weiterentwicklung des Product Backlogs
Wer	verantwortlich: Product Owner (PO) – zu diskutieren mit: Developer (DEV) Team
Wann	während dem Sprint
Wieso	damit PO und DEVs das Backlog auf den aktuellen Stand bringen > neue Storys ersichtlich machen!
Zweck	die höher priorisierten Items im Backlog so vorzubereiten, dass sie sich gut für das Sprint Planning nutzen lassen

Aufnahme von neuen Epics / Features / User Storys / User Tasks in das Backlog
Verfeinerung von vorhandenen Epics / Features / User Storys / User Tasks und ggf. Aufteilung in mehrere kleine Backlog Items
Zusammenfassen von User Storys
Diskussion der Akzeptanzkriterien, Annahmen und Einschränkungen
Identifikation von Abhängigkeiten
Korrektur von Aufwandsschätzung aufgrund neuer Erkenntnisse
Veränderung der Priorisierung aufgrund neuer Erkenntnisse
Entfernen von irrelevanten/obsoleten Epics / Features / User Storys / User Tasks aus dem Backlog
Beseitigung von Unklarheiten durch gemeinsame Diskussion, wobei es um das “was” und nicht um das “wie” geht

Was	legt die Arbeit dar, welche innerhalb eines Sprint erledigt werden soll
Wer	verantwortlich: Product Owner (PO) – Diskussion mit: Developer (DEV) Team
Wann	Sprint-Start (Planning initiiert den Sprint)
Why	um die notwendige Arbeit für ein Produktinkrement zu planen > erstellt den Sprint Backlog
Zweck	Ziel: die wichtigsten Product Backlog Items (PBIs) für den Sprint zu wählen und so zu planen, dass diese auch umgesetzt/geliefert werden können

Warum: Was macht den Sprint wertvoll?
Was: Was kann im Sprint alles gemacht werden? Was möchte das Team alles anpacken?
Wie: Wie kann die gewählte Arbeit erledigt werden? Wie möchte das Team das anpacken?

What	continuous care and enhancement of the Product Backlog
Who	responsible: Product Owner (PO) – to be discussed with: Developer Team (DEVs)
When	during Sprint
Why	to bring the Backlog up to date > show new Stories
Purpose	prepare the Product Backlog with high prioritized PBIs so that they can be used for future Sprint Plannings

include new Epics / Features / User Storys / User Tasks in the Backlog
refine existing Epics / Features / User Storys / User Tasks or split them in smaller Backlog Items
abstract similar User Storys
discuss the acceptance criteria, assumptions and constraints
identify dependencies
correct estimations due to new insights
change the prioritization due to new findings
delete irrelevant and obsolete Epics / Features / User Storys / User Tasks from the Backlog
discuss the “what” and not the “how” and try to remove misunderstandings

To define boundaries: to help development team to know when a user story is completed
To reach consensus: to synchronizes the development team (what conditions should be met) with the client (what to expect from the app)
To have a basis for tests: to check if a system works as expected (positive and negative testing)
To specify planning & estimation: to divide user stories into tasks so that they are correctly estimated and planned

User Story:
As a website user
I want to search on the webpage
So that I can find necessary information.
Scenario: User searches for an item by its name
Given that I’m a guest user
When I open the ‘Products'”‘ page
Then the system shows me the list of all products
– the system shows the ‘Search’”’ section in the right top corner of the screen
– when the ‘Search’ field is filed the name of an existing item will be shown as suggestion
– click the ‘Apply’ button or press ‘Enter’ to start searching
– the system shows products in the ‘Search Results’ section with product names matching entered
– the system shows the number of search results in the top of the ‘Search Results’ section

What	Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint
Who	responsible: Product Owner (PO) – to be discussed with: Developer Team (DEVs)
When	starts the Sprint
Why	to plan the work necessary to create a product increment > create the Sprint Backlog
Purpose	Goal: to select the Product Backlog items for the Sprint + the plan for delivering them

Why is this Sprint valuable?
- PO: how the product could increase its value and utility in the current Sprint
- Scrum Team: collaborates to define a Sprint goal that communicates why the Sprint is valuable to stakeholders
What can be done this Sprint? What do we want to tackle in the upcoming sprint?
- discussion with the PO: the DEVs select items from the Product Backlog to include in the current Sprint
- Scrum Team may refine these items during this process, which increases understanding and confidence
- DEVs selecting how much can be completed within a Sprint may be challenging (the more the Developers know about their past performance, their upcoming capacity, and their DoD, the more confident they will be in their Sprint forecasts)
How will the chosen work get done? How do we want to tackle it?
- DEVs plan the work necessary co create an increment that meets the DoD for each selected PBI (this is often done by decomposing PBI into smaller work items of one day or less)
- DEVs decide how this is done (turn PBIs into Increments of value)
- all together: the Sprint Goal, the PBI selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog
- Sprint Planning is timeboxed to 4 hours for a 2-weeks Sprint

Get clear picture to the “what” and “why”
- Product Owner presents sprint goal and all associated PBIs
- Team (all together) should make Sprint goal clear and easy so that all team members can see AND understand it
- PO answers comprehension questions from the team
Get clear picture to the “how”
- estimate PBIs if that have not been done yet or
- refine estimation if already estimated
- start a detailed implementation discussion
DEV Team forecasts delivery
- DEV team makes a prediction to product owner (and stakeholders) about what PBIs will be delivered at the end of the sprint according to the collaboratively written DoD
- DEV team makes a commitment and form the Sprint Backlog (decide on which will worked obligatory and on which optionally/additionally)
DEV Team breaks down work
- this second part of Sprint Planning often takes place without the PO
- development teams break down the PBIs into smaller work packages (creates tasks or subtask)

Monday	Tuesday	Wednesday	Thursday	Friday
–	–	–	Sprint Planning	Daily
Daily Refinement Tech Talk	Daily	Daily Overall Refinement	Daily	Daily
Daily Refinement	Daily Overall Planning	Daily Sprint Review Team Sprint Review SW Sprint Retro	–	–