Skip to content

Instantly share code, notes, and snippets.

@alvinncx
Last active November 20, 2020 01:34
Show Gist options
  • Save alvinncx/6267c74bc036316acfb8546481cadc01 to your computer and use it in GitHub Desktop.
Save alvinncx/6267c74bc036316acfb8546481cadc01 to your computer and use it in GitHub Desktop.
Scrummaster course 17 Nov 2020

Sprint is a cycle lasts 4 weeks

  • Don't like the name, not sustainable
  • 2 weeks more common
  • No gap or delay between sprints

Stages

Plan

Sprint goal

  • Valuable, clear, realistic, won't change
  • Not changing the goal is important to not affect motivation.

Produce

  • Help coordination, create visibility, surface problems, protect team
  • Protect the goal from changing during Produce stage
  • Only way to change goal is to cancel the sprint

Inspect and adapt

  • Examine carefully
    • The Product, what we are delivering
    • The Process, how are we communicating and estimating, etc.
  • Find future improvements
  • Feed changes into the plan

Kickoff and release

At the start there is a kickoff. Multiple sprints should have a lot of improvements At some point there is a release.

Timeboxing

Do activity to the end of the timebox Got to stop at the end, cannot finish late. Sprints have timebox Planning and retros have timebox Everything has a timebox Prevent processes from taking too long Help us to learn and improve Force improvement

Daily scrum 15 minutes (stand up)

  • Stand in circle
  • Update everyone
  • force the ending of stand up
  • Have to stop

Coaching

  • The coach is important to meet the goal within timebox

Biggest mistakes

  • Sliding on the timeboxing, not enforcing
  • Gradually yielding to more time
  • Chaos is our enemy
  • Team must have buy in

Scrum doesn't work for everyone Do a sample sprint and work from there

The Scrum Team

3 key players PO, Dev Team, Scrummaster. Supporters: help or don't get in the way.

PO

Main responsibility: Maximise value and satisfaction of product It's not about the amount of features, it's about the impact of the features. Needs to have deep understanding of customer and clear vision for the product. Receives input from many inputs but PO must make decisions. It's a specialised role Product Owner can be development team PO can be in 2 teams But PO cannot be the same person as SM

Product Backlog
  • Everything that the product needs, prioritised list of everything needed
  • PO decides the tradeoffs between different dimensions: scope, schedule, cost, quality
  • Different dimenions will pull you away in different directions
  • Must land in the intersection: The Right Product
Dynamics

PO and Dev collaborate a lot

Development Team

Self-organising, Cross-functional Programmers, testers, etc... are all referred to as "developers". Because everyone contributes to the final product, and we don't want them to think in silo.

Cross functional team
  • Individuals who have one of each of the required skill
  • Individuals who have all of the skills needed
Team size
  • Recommended size is 6 +/- 3.
  • Smaller teams tend to work better Colocation helps to commit and communicate
  • the point is to not continue doing what doens't work.
  • make changes to meet the sprint goal.

Scrum is not prescriptive Don't continue doing what doens't work Try something different Experiment and then try for 1 sprint

If Scrum doesn't prescribe the solution, then use common sense and try for a sprint – or a few sprints.

Scrummaster

Leads the chagne Teach and coach Scrum theory, practices and values Referee Scrum rules Encourage trasparency and honesty Remove impediment Protect from disruption Leads through serving not directing

  • Don't take responsibility away from the development team
  • Understand why and then facilitate the team towards a better outcome instead of just spoonfeeding
  • Coach the team to take responsibility, help them be more motivated Most teams are not motivated, SM's main challenge

Impediments & Productivity

Adding more pressure and expectations gives a temporary bump to productivity

  • Burnout will set in and productivity drops
  • Pressure doesn't go away even after productivity drops
  • Impediments
    • anything that slows us down, creates waste and hurts motivation When impediment is removed, productivity increases hence better output People must reduce the impediments, SCRUM does not magically make it go away.
  • Most scrum teams have 70-100 impediments
  • The first step to solve impediment is the most difficult

Techniques

One breath

Wrap things up, capture opinions

Fist of five

Have a scale for opinions

Smallest step

Technical disagreements, can't get consensus Do spike

Viewpoint replay

For deconflicting

Yes, and

Kickoff

Product backlog

Product backlog items

features

Most of the PBI is made up of featuers Attach items to PBIs Some teams use User Stores as PBIs

  • as long as it has direct value to customer

technical items

Things that don't directly affect user

improvements

Things that don't directly affect user

investigations

spike cards

On PBI planning

If PBIs are not planned from user perspective as working features, then we don't know how much of a working product we are shipping. If no working product is shipped, we don't knnow anything about it.

Product backlog refinement (Grooming)

Before first sprint Spilt into smaller stories and slicee

  • Not split into technical components
  • But smaller in scope and complexity Each feature has different value, so prioritse according to value

80% of value is delivered in the first half of all sprints before release

Scope buffer

  • Good POs will put items that can be dropped or postponed at the lowest priority

Sprint estimation

Development team estimates how long the sprint will take

  • Realistic goal
  • Sense of commitment
  • Backpressure to manage team burnout
  • includes feature, and testing and bug fixing
    • testing is done within the sprint so that defects do not snowball
    • agile testing
  • PRI - "potentially releasable increment" The current sprint goal does not change, but can be swapped around
New feature comes in

Can put on the top of PBI, and remove the low value items Value is increased overall, but schedule cost and quality maintained the same. Scrum allows for accomodating changes

Throwing more developers at it

Software development is a game of skill, not a game of scale

PBI that never gets completed

Some PBI will not be completed Can go back to the top of PBI stack or anywhere in the stack according to prioritisaion These can be mitigated with Scope bufferring, schedule buffering, cost buffering

Sprint is completed ahead of time

Use extra time to start next item on PBI or technical items But sprint goal is not changed

Previous PBI needs improvement

Feature goes back into PBI stack

Sprint planning

Start of sprint Whole team is present Timebox 2hr x number of weeks in sprint

Scrum estimation masterclass

Scrum does not prescribe unit of work

  • No need to be entirely accurate, but close enough

Ready to be worked on

  • Small, clear, unlikely to change
  • Anything not ready to work on, will be moved down the PBI

Sprint goal should be realistic - TO be decided by dev team PBI is put into Sprint backlog Sprint backlog is made up to tasks, broken down by dev team

Produce

Daily scrum by product development team

  • Work on yesterday, what we working on, any blockers
  • Keep daily scrum to just updates
  • Sprint goal does not change
  • But sprint backlog tasks can change as the team is working on it
  • PO can join daily scrum, experiment and see if it is effective
  • Do testing within each sprint including uat, automated testing

Sprint burndown chart

Backlog grooming

Looking ahead at items in the next sprint Make sure they are ready to be worked on

Inspect and adapt

Sprint review Timebox 1hr x number of weeks in sprint

  • State of the product now, adapt the product backlog Sprint retro Timebox 45min x number of weeks in sprint
  • How do we want to do the future sprints differently to make it better

What happens to the Project manager?

The job can already be covered by other members of the scrum team Nothing for a Project manager If a project manager is added in, there will be chaos

Retrospective

Book recommendation: Agile Retrospectives

  • It is the core of scrum
  • If people are disconnected and not engaged, then retrospectives will not be effective

Setting up the Scrum team

Product Owner

  • An ex project manager will have to be retrained

Product owner and scrummaster cannot be the same person

Scrummaster

Qualities to help people to work well together Good personality and people skills

Supporters

Stakeholders and experts make good supporters Consider the dynamics and available time to execute on deliverables

Context switching and Multiple projects

Context switching causes drop in productivity

Crafting requirements and story

Too detailed

not helpful

Not enough detail

difficult to understand

Less detailed specification + conversation + inspect and adapt

Best result, allows clarification of stories

User stories

3Cs

Card

It has basic understanding Don't have to include all info needed As a _____ , I want to ______, so that _______

Conversation

Force detailed development team to have detailed conversation Conversations will fill in the other confirmations that are implicit

Confirmation

Write confirmations down after clarifications

Epics

Most user stories start here Epic sized = too big to fit into one sprint Split into smaller stories Not all PBI are user stories

Motivation

The candle problem Carl Dunker Functional restrictive

Reward is counterintuitive... it might not accelerate creativity Contigent motivators don't work, or do harm (if you do this, you get that)

Intrinsic and extrinsic motivators

Business it built around extrinsic motivators, used to work for 20th century era Rewards help to narrow the focus

  • But real problems need peripherial vision

If the skill only needed motor skills, perf is proportional to reward If the skill needed thinking skills, higher incentives led to worst performers

Financial incentives negatively impact performance

Autonomy -- allows us to get self direction Mastery -- better and better Purpose -- service of something better than ourselves

Management is not natural, it like a TV

Atlassian Fedex Days

ROWE

people don't have schedules

Book - Daniel H. Pink - Drive

User stories

Divide and conquer large stories Smaller slices make it easier to test as well Splitting technique At first when looking at the PBI, it is hard to find any scope buffer

Feature slicing

  • Incomplete flow End to End

Slicing by business value

  • End to end
  • Needs to be coupled with good design
  • Extensive use of mocks, stubs

How small should we slice the items

  • Small enough to fit in the sprint, but smaller than that so we can some of them done at the end of the sprint
  • Small enough to fit 6-10 PBI into 2 week sprint
  • 1-2 people can finish in 3-4 days

Slicing by Simple/Complex

Slicing by Positive Negative

Slicing CRUD

Factors to consider

  • ROI
  • Risk
  • Dependencies

PO takes in input from everywhere to prioritise the PBI

  • Value
  • Size
  • Risks
  • Dependecies
  • Efficiencies calculate ROI from all the PBIs
  • from Customers, Supporters, Management, Stakeholders, Dev team

Definition of "Done"

Scrum team creates the definition of "Done" Don't slide on the definition of "Done" Don't lie to ourselves, as we are just going to let problems snowball

ScrumBut: The Product Owner is responsible for only scope and quality.

Avoid changing the DoD in later sprints DoD should be stable

Case study

Definition of done missing Performance testing

  • Definition of done looks like it is too difficult to achieve with manual methods
  • Automated test tools Practices that get PBIs truly done also help to reduce impediment

Scrum tools

Information Radiators

  • Big visible charts
  • Force developers to self organise

Warning: Tools can make it hard to work.. No need to stick to the same tools

LeSS

Large scale scrum

  • Feature teams
  • PO may be on 1 or more feature teams
  • Chief Product Owner
  • SM can be shared as well
  • Chief Scrum master

Dev Team coordinations

  • Scrum of scrums from dev team representatives Product Dependencies Many options
  • Moving low priority dependencies to higher in PBI
  • Moving high priority lower in the PBI
  • Stub the interfaces
  • Pass the story to the team that needs the dependencies

Scaling scrum

Adding things on top of scrum Scrum+

  • LeSS
  • Scrum@Scale

The 5 whys analysis

Ask why at least 5 times

Sprint estimation

Estimating small things, we are accurate using real world estimation units But when it is complex and abstract, it is difficult to do so For product backlog - Use relative units or real world units For sprint backlog - User real-world units like days, hours or quarter days

The total points changing between sprints

  • Learning curve on understanding of estimation
  • It is assumed that the capacity will change between sprints due to team life plans and other processes
  • Average points per sprint = "Velocity"
    • It is only an average. Don't make judgement based on one sprint
    • They are not convertable to hours or vice-versa

How to use points

Use points to calculate total Use total divided by velocity = total sprints Multiply sprint length to give estimate delivery date and estimated cost

  • Point is measure of SIZE not EFFORT.
  • Points must be DIMENSIONLESS and they are RELATIVE.
  • Points must have reference stories.

Estimate Release date and cost

use Planner poker to estimate points Size is a blend of effort, complexity, uncertainty. Must estimate overall size of the item If numbers are wrong, they are we doing it?

  • quick rough estimates accumulate to low errors

Product owner takes total size and divide by velocity

  • This gives the total number of sprints
  • Uncertainty 15%
  • Rework and improvement buffer 10%
  • Additional sprints
    • Sprint zero kickoff
    • Pre release sprint

Calc velocity

Exclude sprints that are outliers Take the average of the velocity

  • Estimate with proxy or historical projects
  • Use best case, worst case estimation
  • Simulated sprints
  • If no team yet, pick an "average" team but reduce the velocity expectations Don't let sales team estimate the story point or estimate.

Release burndown

At a glimpse, able to see how the project is doing Works similar to sprint burndown Able to extrapolate the possible release date

If release is behind the schedule

Use the data to de-scope the project Delay items Increase cost and stay on track Reduce scope, simplify low priority items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment