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.
In video games, there are many side-quests to getting to your primary quest. They might give you XP (experience) to help in your primary quest (i.e., unit testing, additional coding, etc, etc). We sometimes discard them because – “Bah, when am I going to use this” – but then when we complete the primary quest, we begin the work to go back and clean up our side quests and think – “huh, this would have…
They want to know how they are doing. They want to know what they are doing wrong. They want to know where they need to get better. They want to know what to fix. So they crave it, in any form, they want it, all the time – feedback, not validation, not comments, but feedback – how do I get better? Tell me.
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…