I’ve done 1 week to 6 week sprints (yes at 6 weeks we called it a sprint) – if you’re not sure what fits best for you, here’s some guidance. 1 Week – It’s all bugs, it’s all known quantities, you have minimal code and your deployment model is code, commit, deploy. QA happens when you ship to Production, teams of 1 – 2 developers. The Theme is “MVP”. 2 Weeks – User Stories are…
Can we put everything into this fix to get it right and get it out there? Have you tried putting everything into one fix? I remember when 100 MB was considered too big for a patch and now I’m downloading 20 GB updates. Focus your fixes on the problems they are meant to solve – no one ever complained about a fix that addressed the one issue it was meant to.
Do you ship by date? By state of quality? By bugs left on the table? By customer adoption rates? By pre-order? Do you grind late into the night on the last few weeks to get it all done? Do you lay out your sprints so you have time to work on the unknown as it arises? Do you pushback on new requirements? Everything has to be cut in stone? Often times our delivery profile is…
If you can’t code 8 hours a day. Can you jump in, on small tasks, and hammer out 1 hour a day? If you can’t do 5 hours a week can you find time to do 3? Bit by bit is the origin story of many overnight successes.
The next Release is always going to be the best. Until that work gets pushed to the next release. If you commit to fixing everything now, this release will become the best release where you fix everything and next release – who knows what next release will be because you won’t be spending all your time trying to fix it.