In the previous parts we have learned how to write stories, groom and point them. Everything up until now has been done to prepare us to be able to plan a sprint.
Planning a Sprint
Planning a sprint involves taking a group of eligible issues and batching them together and getting agreement from the development team that they think this amount of work can be accomplished in the given interval.
The planned work represents good faith committment that the team thinks they can accomplish the tasks under normal working hours.
There should not be the expectation that developers work over the weekend to make sure the Sprint is a success. That's simply not sustainable and sets a bad precedent. Life will happen. People will get sick. Estimates will be wrong and things be more complex than originally thought. It's ok. We roll with it.
The sprint plan is a goal.
As time progresses the team will become better at hitting the goal and be more predictable, but it will take some time to get there.
Velocity
This is where the story points help a lot. After a few sprints the team will have established what's called a Velocity.
This is simply a rolling average of how many story points are being delivered per sprint. This number can then be used to estimate how much work the team can take on in another sprint.
It can also be used by the Product Owner to project how many sprints away are we from being able to deliver features groomed and pointed in the backlog.
Very powerful stuff.
Running a Sprint
Inside a sprint you can have any number of phases.
For Eldarion, we decided to map the process that worked well for us on Trello here to function inside each sprint:
- To Do
- In Progress
- In Review / QA
- Accepted
We will go from To Do to In Progress as developers pull work and self-assign and start hacking. When they are complete, a pull request will be generated, peer reviews happen, and then it's deployed to a test instance. Once this is done the issue is moved to Review where the Product Owner will review the work against the acceptance criteria and accept or block the issue.
You can find more detail on acceptance criteria and blockers in our previous posts, How We Use Trello: Acceptance Criteria and How We Use Trello: Blockers.
Once work is accepted, the issue is moved to Done, otherwise the issue is flagged and feedback left for the developer on why it is not acceptable. From here the developer and product owner iterate on conversation, code tweaks, and redeploys until it can be accepted.
Conclusion
All the work we do as part of our scrum process including building a backlog, grooming the backlog, and pointing the backlog, all culminate with planning and running sprints.
The prep work done along the way supports a sprint running smoothly and efficiently. And don't worry if your first sprints (or even later sprints) are not smooth and efficient. This isn't about perfection, but rather constant improvement. Learn from the past, improve on the future.