Search code examples
gitdeploymentscrum

Deployment strategy for Scrum

According to Scrum at the end of a sprint, we have to create a working solution (build, concept, code). For example, the sprint duration is 1 week, and according to priority we need to pick up an issue that may take more than one week. We are using a strategy to commit everything to the master branch and we don't use branches for issues; it's done to avoid double testing of issues. We can split a big issue into small tasks, but still, at the end of the sprint we won't get a working solution. So the only way for such an issue is to develop it in a separate branch.

Maybe you have any other ideas, propositions?

Solution

  • Your stories should to fit the INVEST properties. the "S" debatably stands for "sized appropriate" or "small". As in "small enough to fit in a sprint". Since your sprints are not big enough to contain some of your stories you have two choices:

    1. Split the story. I don't mean simply making it into smaller tasks, but slicing it into pieces that still deliver value but fit within the sprint. There are a few examples of how to do this in this great book User Stories Applied. I'm certain you can find more examples around the web as well.
    2. Make your sprints longer. If this is occurring frequently, I would suggest making your sprint 2 weeks long. I've found one week sprints to be a little short so this would be my suggestion.

    In regards to how you branch (or don't branch) the code in git, that's really a personal (or team) preference. If you've got good automated testing, it shouldn't matter. If you don't, then making the story fit in the sprint will allow you to not branch, not test twice, and stick to your current process.