-
Notifications
You must be signed in to change notification settings - Fork 1
Sprint Plan
“A Problem Well Stated is Half Solved.” - Charles Kettering
Developers have the right to refuse to do work if it has not been clearly outlined within a sprint. This plan will describe the ins and outs of what makes life easiest for developers which in turn carries the project towards deliveries.
Sprints are required to be a minimum of 2 weeks, 10 working days no shorter than that or the result is stressful, incomplete, rushed and full of bugs.
There is to be at least 2 days worth of testing done at the end of the sprint. If possible testing will be completed by people other than the developers so they can continue to work. Otherwise developers will take that role. If new features aren’t completed before the 2 day testing period begins, the feature will be put into the release of the next sprint not during testing.
There needs to be a release/deployment day where all testing is signed off and agreed that we are delivering the required functionality that was outlined during the sprint planning. Work that wasn’t completed should be discussed in a retrospective so that we can decide if we push it into the next sprint or put it on hold temporarily while we complete other tasks.
After the sprint retrospective we immediately start planning the next sprint. There should be a consistent flow from sprint to sprint without variation. Ideally sprints should start on Monday and end on Friday. We can change this to a day that better suits everyone but whichever day it is we stick to it and carry out the 2 week schedule from that day going forward.
We don’t work sprints around deliveries, we work deliveries around sprints.
- Sprint length is 2 weeks or 10 working days
- Mandatory 2 days worth of testing at end of sprint
- Mandatory 1 day for sign off and release
- Total development time 7 days
- Mandatory end of sprint retrospective
- Deliveries are worked around sprints
To manage the expectations of what will be delivered during the sprint. Developers should be planning to have all their tasks completed within the 7 days of development.
By following this any task a developer might be struggling with or might have unforeseen problems has an additional 3 days to work on it. This should ease the pain of carrying work from one sprint to the next. Testing, sign off and release will still go ahead as planned but without that feature in the released deployment.
Estimations should follow this framework to keep the process simple and consistent:
- Couple of hours (0.5)
- Half a day (2)
- Full Day (3)
- Couple days (5)
- Half a Week (8)
- Week (13)
- 2 Weeks (20)
- Work should be planned to be completed in 7 days
- 3 days admitted for uncompleted work
- Testing and release go ahead as planned
- Uncompleted work won’t be included in the release
During the 2 days of testing Staging should be in a code freeze as outlined in the Coral Testing Plan document. The only changes going in during the freeze should be urgent fixes or blockers. Absolutely no features should be merged in during this period.
- Testing equals code freeze
- Only changes allowed are urgent fixes or blockers
- Absolutely no features
- More detail provided in the Coral Testing Plan
At the end of each sprint there will be a meeting arranged. The meeting will start by discussing the results from the testing period. We need to ask questions such as:
- Are we stable to release?
- Are there any blockers?
- Can the user carry out their job?
- Do the features meet the requirements laid out?
Following that the project manager and product owner will sign off on the sprint being completed with the work that was able to be delivered. This does not include incomplete work that developers might still be working on. It wasn’t possible to complete so it’s not going in, no exceptions.
Once the sprint has been signed off there must be a retrospective carried out. This is where incomplete work will be discussed and we have to ask questions such as:
- What did we not expect about that piece of work?
- Did you manage to complete the work outside of the 7 day period?
- Should this work be carried into the next sprint?
- Can someone help you complete that piece of work?
- Was the communication during the sprint satisfactory?
- Did we have clear and understanding expectations for this sprint?
- Did we agree to take on more work than was possible?
- How accurate were we in our estimations for the work?
All this information should be tracked in a new document with the date of sprint. So we can keep track of where we’re failing and where we’re improving during our sprints. Create a copy of End of Sprint Template.
- End of sprint meeting
- Start by discussing testing results and ask lots of questions
- Following testing PMs will sign off on the sprint
- Retrospective will take place
- Uncompleted work will be discussed and planned to be resolved
- Each end of sprint meeting and retro will be documented
In the event someone is on leave, has holidays, is sick or has responsibilities they need to attend to. The sprint planning will go ahead. If they are the person usually running the sprint, someone else will run the sprint. Play rock, paper, scissors and take turns running the sprint.
If we’re aware they are gone for only one week of the sprint. Work should be planned for them coming back. If they’re gone for a day, work will be planned for them returning.
No matter the availability of team members, sprints go ahead on the same day at the same time every fortnight.