Scrum Working Normally

Structure of the Scrum Team

  • Scrum Master –  (Removes Noise/ Blockers and Shields the team from distractions)
  • Tester  –  (Provides independent test that validates / supports the development work performed by the Development Team )
  • Developers
  • Product Owner
  • Test Team
  • Technical Project Manager

Scrum Team Primary Contacts In A Project

  • Product Owner
  • Test Team
  • Technical Project Manager

What Scrum Team does  / What the Scrum Team doesn’t do

What they do What they don’t do
Takes the requirements from the Product Owner and creates the stories to work from Define the Sprint Goal (Product Owner responsibility)
Estimates the complexity of stories Decide if to release the  developed code into production environment (Product Owner responsibility)
Defines what “Done” means in the development team – Ensure everyone understand the team’s definition of done. Cancel a sprint
Only commits to timescales they believe to be achievable in the sprint.
Reports on project status to project team within the boundaries of Scrum
Ensures that they deliver production ready code at the end of every sprint
Are unhappy when they fail to deliver all stories for the sprint – it is classed as a failure.
Self–organising team, deciding on what they develop and how.
Perform the ceremonies associated with the Scrum Methodology ( i.e. daily stand ups, planning & review)
Add Acceptance criteria to the sprint stories

Working With Distributed Scrum Teams

  • At the start of projects get all the team together and Whiteboard / face to face meeting / bring the teams together to build up trust
  • If you can’t get the whole team, send ambassadors from the team.
  • You are going to pay for a face to face meeting regardless if you have it or not. If you don’t have it you will pay more!
  • Go to both offices
  • Peer to Peer relationship are the most important relationships within any team. Trust is key to success
  • Problems you can’t solve over email or when you are looking at each on skype and you can’t see the solution – Get another face to face meeting  and GO FOR LUNCH!
  • Product Owners should be available in the local location at regular intervals so that developers can build rapport and ask questions to them.

Standard Scrum

  • Only the Scrum Team can change the sprint backlog.
  • Scrum Team consults the Product Owner if commitments are unachievable.
  • Product Owner removes lower priority items from sprint backlog.
  • Product Owner cannot introduce new stories during a sprint.
  • Needs to allow for turn-around of new critical defects etc…
  • Do not plan too many “Must Have’s” into the sprint – typically 60%
  • This allows for some scope within a Sprint.
  • Amount of “Must Have” effort must be agreed by the Scrum Team.
  • As well as having a digital scrum board, have a visible physical board which display status of the current sprint so that all can see it. (In Scrum we make all information visible to all interested parties)

Common Pragmatic Implementation

Sprint Information Radiators

 

Cancelation of a Sprint

  • Can only be done by a Product Owner.
  • If requirements change too much and sprint goal no longer makes sense
  • If team feel that Sprint Goal cannot be achieved
  • Stop, re-plan and start another sprint (BUT only until the end of the original sprint length)
    • Cancelling a sprint due to changes in requirements should be done only as a last resort.
    • In theory, the work performed during a cancelled sprint is removed from the source repository and the work is lost.

The Costs of Cancelling a Sprint Due To Changes In Requirements

Cost = Length of time already in the Sprint (T)  X (The Number of Developers involved in the Sprint (ND)   X  the average day rate of the developers (R) )

Cost  = T x(NDxR )Total Cost of Cancelling    €11,250 lost to the Business T: 15 days (Three weeks into the iteration)ND: Number of Developers = 3R:  Average daily rate  = €250*15 x (3 x 250) = 11,250(*assumed rate)

Changes of Requirements

  • Changes in Requirements impacts on the effectiveness of the Scrum Team.
  • Wait until the next planning session, when the work is prioritised against the current backlog of product items.
  • The work is sized by the scrum team and the Product Owner removes a similar sized story ( or stories) out of the current Sprint backlog.

 

Improvements in the Build Quality

  • Implement Test Drive Development(TDD) approach to increase the coverage of tests across the code base.
  • When new code is developed a suite of tests are created to support the code and the functions within.
  • When old code is changed a test is written to replicate the current functionality before making any changes. Once under test, the code can be safely changed to implement the new functionality, ensuring that the test still passes.
  • Commission a Continuous Integration server that runs the test created via TDD whenever code is checked into the source repository.
  • Set a minimum test coverage level to the Build Server, failing the build if it falls below that level.
  • Follow best practices when using Source Repositories (i.e. tagging of releases, comments when checking in code)

Support Calls

  • Define a definition of what a “bug” is so that all people understand what a bug is and what it is not.
  • The Scrum team operates with a velocity that includes a story specifically for handling support issues.
  • Create a story and size it from the last sprint support call.
  • As support calls come into the team the bugs are prioritised by the Product Owner and are either kept back to be planned into the next sprint or are sufficiently small or sufficiently high profile to be put into the current sprint.

Support

Project Management  – The Sprint Life Cycle

  • The sprint is broken down into 4 weekly cycles.
  • At the end of the sprint the sprint is reviewed, work is showcased to the project stake holders and the next sprint is planned.

Sprint Planning

ALL the scrum team is involved in planning for the next sprint – not just key individuals.

  • Product Owner & Scrum Master meet regularly to refine the stories in the Product backlog.
  • During the last week of the iteration the Scrum Team meets to discuss POTENTIAL stories for the next sprint.
  • The work done in the previous sprint is  DEMONSTRATED to the stakeholders, who then provide FEEDBACK to the team. By scheduling with stakeholders as the first activity at the end of the sprint it STOPS the developers requesting 1 more day to complete the sprint.
  • How the team worked in the previous sprint is reviewed, where suggestions and IMPROVEMENTS are made by the Scrum Team.
  • Planning takes place when the stories for the next sprint are PRESENTED by the Product Owner to the Scrum Team.
  • The stories are ESTIMATED by the Scrum Team and if they feel that they can deliver them in the next sprint are added to the sprint backlog.
  • The committed stories are BROKEN DOWN into smaller task and assigned a TIME ESTIMATE.
  • The time estimates are compared against the available time in the sprint. If there is insufficient time to deliver the stories the Product Owner REMOVES items from the Sprint backlog. The Sprint is then LOCKED until the next planning cycle.

Story Grooming

  • Purpose – Ensures that the Product back log is relevant and prioritised
  • How often – Once every 2 weeks
  • Length of Time – 30-60 minutes
  • Roles Involved – Scrum Master & Product Owner

Pre-Sprint Planning

  • Purpose – Stories proposed for the next sprint are reviewed and discussed by the Scrum Team & PO in order that they can think about potential tasks involved.
  • How often – Every day in the final week of the sprint.
  • Length of Time 30 minutes per day
  • Roles Involved – Scrum Team & Product Owner

Sprint Review

  • Purpose – The project team showcases to stakeholders the work done since the last sprint. Feedback from the Stakeholders is noted and may be added to the product backlog.
  • How often – At the end of the Sprint
  • Length of Time – 2 hours (if required)
  • Roles Involved – Scrum Team, Product Owners & Stakeholders

Retrospective

  • Purpose – The Scrum Team reviews their performance over the last sprint. Looking at estimates, bottlenecks and improvements  in working practices.
  • How often – At the end of the Sprint
  • Length of Time – 1 hour
  • Roles Involved – The Scrum Team, Product Owner if the scrum team is comfortable with their attendance.

Sprint Planning 1 (SP1)

  • Purpose – Top Down Planning – The Scrum team commits to the amount of work it believes it can complete in the next sprint.  Comparing and estimating the complexity of the stories against each other in order to size the amount of work being asked for. Product Owner is there to answer questions – not to size the tasks.
  • How often – At the end of the sprint
  • Length of Time – Approx. 1.5 hours
  • Roles Involved – Scrum Team & Product Owner

Sprint Planning 2 (SP2)

  • Purpose – Bottom Up Planning – Reviewing the task committed to in SP1, breaking down the stories into  tasks and assign a time value to the individual tasks. Again, the Product Owner is there to answer questions – not to size the tasks.
  • How often – At the end of the sprint
  • Length of Time – Approx. 1.5 hours
  • Roles Involved – Scrum Team & Product Owner

Story Planning 1 – Top Down Planning

Stories are sized against each other and their complexity is estimated using a nominated scale e.g. Fibonacci sequence , 1,2,3,5,8,13,21….

Stories Story Points(sp) – Complexity
Example 1 8sp
Example 2 5sp
Example 3 8sp
Example 4 3sp
Example 5 21sp
….
 

The total of the stories are added up to give the overall number of points committed to in the iteration ( the team’s velocity).

Story Planning 2 – Bottom Up Planning

Stories are broken down into individual tasks which must occur in order to complete the story

Story Vs.  Task  Time           Hours

Example 1

7

7

7

7

7

35

Example 2

0

7

7

7

0

21

Example 3

7

4

4

8

7

30

Example 4

2

2

2

0

0

6

Total

92

Resource A works every day on the project and can commit 7 hours per day

Resource B works 3 days out the week

Resource C works every day on the project  and can commit 7 hours per day

Resource D is on other projects and can only commit to 2 hours for 3 days

So over a week, this team can only commit to 97 hours

Task Analysis in Hours

  • If the number of hours estimated is greater than the amount of hours available to the team then the team has over committed
  • The Scrum Team asks the Product Owner to remove a story for the next sprint until the number of hours committed to is below  the number the number available to the Scrum Team. The stories removed from the list are the normally the lowest priority in the sprint, but on occasion removing a larger story will enable delivery of more features – the choice is the Product Owners.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s