Scrum Sprint Guidelines

This document outlines the guidelines for Scrum Sprints at Ketek. However, each team has the freedom to make changes and self-organise.

Definition of done

User Stories should only be considered ‘done’ or ‘completed’ when all of the following has been done.

• Code complete
  • • Designed and reviewed
    • Code + comments
    • Code Review
    • Refactored
    • Tested
    • Meet coding standard
• Test complete
  • • Test plan created
    • Test plan reviewed
    • Test plan run and passed
• Bugs fixed and verified
  • • All bugs that are assigned to the sprint should be completed.
    • Bugs that are introduced during the sprint should be fixed by the team. If a bug is created, then it should be automatically assigned to the current sprint.
    • Bugs from the backlog or newly exposed ‘old’ bugs should only be added to the sprint if the PO, SM and team agree. The Team should be asked to estimate the bug fix and the PO should decide what to remove from the backlog.
• TFS complete
  • • PBI should have been broken down to tasks
    • Each task done
    • PBI status set to done

Guidelines

1. Daily builds should be created. The team will decide on the time and who should make the build, although if you’re working on the main branch, it’s recommended that you’re changes are included in the common daily builds.
2. All code should be peer reviewed before integrating it into the daily build.
3. The QA member should be involved every day. If they don’t have testing or test planning tasks, then they could take on some of the research tasks.
4. Additional User Stories should not be added after the sprint planning meeting, unless the scrum team and Product Owner agree.
5. All members of the scrum team should be present in the sprint planning meeting, including the testers.
6. If a member of team won’t be able to attend the daily scrum meeting, a status report should be sent to the Scrum Master: Yesterday, Today, impediments.
7. Daily scrum meeting should take place at the same time and place every day if possible.
8. Bug fixing tasks should be added to the user stories and the number of burned hours updated.
9. Hours remaining should be updated for tasks that you have worked on but haven’t completed so that TFS can calculate the capacity correctly.
10. It is Ok to add tasks during a sprint, but the Product owner should approve it first.
11. If it looks like we’ve underestimated the work, then the Product Owner should be informed and one or more user stories should be pushed back to the product backlog.
12. The team should communicate via the TFS Team Room, so that everyone can participate and so that a record of the conversation is maintained in TFS.