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 )
- 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.
- 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)
- 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.
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.
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.
Sprint Planning 1 (SP1)
Sprint Planning 2 (SP2)
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….
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
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.