How to Improve Your Sprint Planning
Several years into agile software development methodology, I can conclude that the process is tricky, to say the least. Adopting an agile methodology includes rituals. Rituals that are meant to help you focus and ensure a more productive sprint.
Personally, I feel that these rituals do not provide enough clarity on how to complete all the planned tasks over the course of a sprint’s workdays. So, I spent a lot of time thinking about how to become more consistent in executing the sprint as planned, which is how I came up with six principles that enable me to overcome this challenge.
If you want to improve your own output or your team’s individual time planning skills, take a look at these six sprint planning output principles:
Research your stories
- Understand the context. Answer the following questions to make sure you fully understand the need:
- Who are your potential users?
- What are their pain points?
- Why is the current solution not good enough?
- How will the changes you develop impact the user?
- How will the changes you develop address the user’s problems?
By answering these questions, you will understand the context of all the problems at hand. Moreover, this knowledge will allow you to be more confident in your work as you are not just building cool UI or smart automation, you are (also) actually addressing real customer needs.
2. Understand the complexity. Break down the affected areas of the code: the components, modules, packages, concrete files, and effects on the system.
Next, consider the integration points for your design. By doing so, the level of complexity will become clearer, which will help you choose code reviewers and make a plan for the coding session.
Divide and Conquer
Consider splitting your work among multiple developers. Then, ask yourself “How can I divide my tasks into small puzzle pieces that can be done (ideally) in parallel?”
Ideally, you’d want to end up with various small tasks. Each task should be scheduled in the developer’s individual sprint, which will help track the project’s progress. That way, you’d be able to estimate how long it takes to complete both the small tasks and the overall project with high confidence.
Small tasks can be further divided, as you see fit, into subtasks. Think of these as a ‘to do’ list of your task. For example, say that this sprint you are assigned with “enabling the user to pay a bill” — the ‘to do’ list might consist of “create a ‘Pay’ button,” “create a utility function to calculate the amount owed,” and “create a new API endpoint for bill payment.”
Remember to make every subtask on the list as small as possible (if you think it can be smaller, try splitting it into two subtasks), and avoid interdependencies as much as possible.
Define your DoD (Definition of Done)
Create a set of requirements that will help you assess your work progress — and more importantly — when your work is truly finished. A simple ‘checklist’ will help you make sure that everything is in place and nothing is missed.
Here is the checklist (feel free to add your own steps and customize it to your needs):
[🗸] Verification. The code must be reviewed and tested by another engineer. Testing information/instructions should be provided in the associated ticket.
[🗸] Sign-off. Align with your team on who is the right person to sign off on the task. While a new feature might require the final approval of a Product Manager or a UX/UI Designer, a bug fix might require the QA Engineer to sign off. Plan your sign-off process together, or check in to verify whether or not this process is already well-defined.
[🗸] Deployment. Have a deployment plan in place. Is there a gradual rollout or is this a big-bang release? Will you deploy to a sandbox environment first? Will you be able to roll back? What are the analytics and conditions you will be looking at to determine whether or not you should proceed with the rollout? You should prepare these details along with a schedule, which you will share with colleagues in order to get all of the support you need.
[🗸] Monitoring. Define analytics, logs, or any other success measuring methods (i.e. the way you know your feature/fix/change is working and is having the intended impact.) Prepare alerts, dashboards, or instructions on how other team members can get information on the project’s status.
Choose your code reviewer in advance
The code review process is crucial for each and every code snippet that integrates into your system. Designating a code reviewer in advance results in better code reviews since the reviewer has added context. In addition to reviewing your code’s logic and adherence to standards, they will be better equipped to review your solution to the actual problem. For best results, keep the same reviewer for incremental commits around the same feature.
Better preparation ⇒ better Code Reviews ⇒ Better feature quality
My personal tip: Select your code reviewer by considering the combination of each developer’s expertise in the technical stack you are working in, as well as their familiarity with the relevant business logic.
I would weigh the first requirement more heavily, as you can always have a primer on the associated business logic, but building up subject matter expertise in a specific technology takes time and experience.
Document your tests in advance
Tests are something that I see as a personal commitment. This is something I must take on before my code integrates with the existing codebase. As the author, it is my responsibility to make sure that nothing breaks as a result of my new code. Moreover, I do my best to ensure that my code will not break in the future when additional changes are introduced (by myself or anyone else).
Thus, you should consider two types of tests: manual and automated.
If — Automated tests: Understand what type of automated test can serve your needs bests (e.g. unit tests, integration tests, UI automation, etc).
Else — Manual testing: Prepare a test plan that takes into account the happy flow, failure scenarios, and corner cases.
To ensure everything works, be sure to document what type of test you’d like to implement ahead of time.
Understand which stories should be postponed
As an experienced developer, I tend to mistakenly over-commit to tasks. I tend to think that I can complete a large number of tasks while making premature assumptions at the point of estimation. Finishing the sprint with multiple leftover tasks (which happens more often than not), helps me understand that it is often impossible to accomplish everything at once. Especially when everything is planned by projects and not by small tasks.
Once you start to perform better task breakdowns, and thus, make better point estimations, you’ll realize that some of the tasks will simply not fit in the sprint. If you cannot do everything at once, it is better to finish some tasks than to start working on multiple tasks without finishing any. Thus, the following understanding is crucial: You should drop lower priority tasks so that you can finish the important ones.
— — — — — — — — — — — — — — — -
There are many ways to become more productive and improve your processes. I hope that by following these tips, you will find yourself accomplishing most, if not all, of your commitments each and every sprint.
My teammates and I at Rewire certainly try to put these principles into practice every sprint. If you’re interested in learning more about our work, check out our blog: https://medium.com/rewire-to
