Sprint Planning is not easy.
Your first few sprints will be a mess as you try to figure out the perfect balance between productivity, delivery, and usefulness.
When getting started, there are some red flags that you want to be aware of to ensure you are getting as much out of it as others.
- If you are working on work that no one is going to look at for another two sprints, you’re probably working on it at the wrong time (because you will end up working on it again in two sprints, thereby duplicating your efforts).
- The bulk of a SCRUM should not be spent on what you did (we have tools that can tell us), what you are doing (ditto) but rather what are you challenged on AND how can the team help (the second part is often dropped).
- Working in a sprint is not an excuse to forget things like performance, error handling and logging.
- Sprint development is not an exercise in quick and dirty code, taking shortcut style of coding (you should be focusing on the MVP but an MVP is not about shortcuts but rather delivery objectives).
- If you don’t know what sprint is being worked on (because they are rolling over for the sake of rolling over).
- If you are never discussing how a sprint went after it is done before starting the next one (not a day-long retreat, a 30-minute wrap-up will do)
If you are using daily SCRUMS to manage your sprints the best question to always be asking yourself – Is this making me better or am I still making the mistakes as I was before? – avoiding the above red-flags and asking the above questions are a great way to ensure you are constantly iterating and improving on your journey to get better.