How often to you release during a sprint. Only at the end of the sprint or every time a feature is ready. And how to you handle bugfix releases?
Scrum Practices – How Often to Release in a Sprint
release-managementscrum
Related Solutions
in some ways it's good that you're slow at the end of a sprint, that means your estimating well and not over committing, as far as keeping busy, on scrum teams I have worked on we always added research tasks for what's coming up next sprint.
This could be doing proof of concepts for things that are coming up, or looking at where to re-factor existing code, working on getting better test coverage on your code, etc.
At the beginning of the sprint there is nothing to test yet
Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about?
at the end of the sprint there is typically nothing or very little left to develop/fix
I have never been in that place in a project. No more work to do? There is always something. Are all your tests fully automated? How is your CI looking? Could the database access layer be refactored to be simpler? And I've never worked on anything with an empty bug list and backlog. What did your developers used to do in a waterfall testing phase?
I know some people get very religious about what is and what is not 'SCRUM'. I couldn't care less about that. But I think you have two issues here:
A 'traditional' QA department that test code once it is 'finished' by developers rather than working with customers and developers to make sure you are building the right thing as well as building it right. Take a look at the agile testing quadrants by Lisa Crispin. The best testers are involved in every stage of the software development lifecycle and the best developers write their own tests.
Trying to stick too closely to a SCRUM timetable of 1 week / 2 week sprints without having a prioritised and sized backlog that is split down into tasks that are easy enough to complete within a short amount of time within a single sprint. If you had this then there would always be more work to get on with. Maybe the last feature you work on in this sprint doesn't get in to this sprint's release, but it can always go in to the next one.
Aside. If you have a small cohesive team then the roles matter less. Instead of having someone with the label tester who isn't allowed to write production code, or someone labelled a developer who thinks they are above testing, everyone should be doing whatever is necessary for the team to succeed, including the dreaded project management tasks when they are necessary, this is called a cross functional team.
One extra point brought up by @Cort Ammon in the comments. The agile manifesto talks about customer collaboration over contract negotiation. You say that:
the client may be disappointed to see the team waste time on something that does't bring immediate value
It can be difficult to explain and I understand customers can be very difficult at times but this would be a big red flag for me. They are trusting you with their source code / client relationship / business / whatever you are developing for them. If they can't trust you to act professionally in their best interest then either you have a problem or they do.
I have written a post that talks about software developers not being considered professionals. A professional doctor, lawyer, civil engineer faced with a client who changed the requirements on them part way through would not just reduce the quality and moan about it. They would tell their clients that it would be a problem. If the client pushed then a professional would not just blindly do it to a dangerously inferior standard because they would be liable. We don't take professional entrance exams and so are not liable. That doesn't mean we shouldn't try to be better.
In summary, I wouldn't worry too much about trying to get people to be more efficient at the beginning and end of a sprint but rather see it as a symptom of a wider issue within the team. Have you heard of eXtreme Programming (XP). I'd say the principles from XP to apply here are communication and respect:
- Respect your team to do what they think is best. I would argue that if there is a lot of watching cat videos then either you have poor developers or you are treating them poorly.
- Communication. If your developers are talking to each other, to the testers, to management, to the customer, then everyone should probably have a good feeling of what is up next and if they don't then they can just ask.
Best Answer
TL;DR: Release whenever appropriate
We do releases whenever there is value in doing a release. Sometimes that means doing a release after a single feature or bugfix is completed. Sometimes that means releasing a collection of features and/or bugfixes.
This doesn't mean we often have "emergencies" that require fast releases. It means we've worked hard to make releases easy. Our code is tested, tagged and packaged with every build. We use automated acceptance tests and as a result we have developed a high amount of confidence in the code that passes it's tests. Since our packages are immediately available via a local yum repo deploying a release is trivial.