Some slack should be incorporated into the schedule to allow things to run smoothly. This is like a motorway, where everyone can only drive at the speed limit if it is less than 80% full.
There are different ways of introducing slack. It can be that some low priority tasks are scheduled, so that they can be pulled if necessary. Or time to learn, write internal tools, and clean up the code can be scheduled.
A technique which innovative companies like Google have is to schedule an ‘innovation’ day every fortnight or so. I like to have these day between iterations.
This is a very effective way to improve the code and to promote knowledge sharing. The person doing the review does not need to be a senior developer; these reviews work equally well if the reviewer is junior, as mostly the person presenting their code will spot their own mistakes when they explain it to someone else.
A good way to introduce it is to start off by doing it in easy situations where you can see how to do it, and then as your skill grows to gradually tackle harder and harder cases. Also do it first on stories which don’t have a close deadline, but where there is enough time to spend a bit longer on it.
The company’s key asset is the code base. Investing in the code base is crucial if you want to be able to continue to maintain the code over the long term.
Don’t let the backlog get too long. Only contain as many stories as can be completed in two to three months.
As well as keeping the backlog on the wall, email it to stakeholders regularly.
Try to run the meeting differently every time.