Development sprint is a vital component of Agile software development methodology, which is focused on iterative and incremental development. Sprints are time-bound periods during which a development team works on a set of tasks or user stories, with the goal of delivering a working product increment at the end of each sprint. In order to set the sprint workflow efficiently, we prepared some pieces of advice to help you out.
Back to user stories
Let’s start off with a little recap. If you’ve been attentively following this development lifecycle series, you will remember the Defining MVP article. One of its primary steps was aimed to help list and prioritize your application features, and the output of this step was a list of selected epics and user stories. Back then we agreed that this list is going to serve as a guide during the development process, so it’s time to come back to it.
Note: You can find a lot of information about epics and user stories, so we won’t stop here explaining too much about them. Instead, let’s focus on the processes you need to follow.
Take a look at your list of epics and user stories that represent the overall functionality of your future application. Most likely, at this moment the list is still pretty high-level, but that is not a problem, because we are going to break it down until we get smaller, more manageable tasks or user stories out of epics and larger user stories.
But what is the purpose of such an approach, you may ask? The answer is simple: to obtain specific, actionable, and achievable tasks that can be completed within the timeframe of a sprint. There is no universal way of breaking down epics, it’s usually a question of improvising and seeing which patterns work better for your team. Anyways, here are some approaches for you to try out:
CRUD: Feature sets can be split into separate actions users can do within your application: create, read, update, and delete stuff. For example, if you working on creating a marketplace, users will be able to add products to the shopping cart, create new orders, and so on - all these actions can be represented as user stories.
Data-based: Some user stories might display a company’s data, while others display the contact information, etc.
Operational: Cut down epic to its minimum viable feature and then add additional pieces of functionality on top
The outcome of breaking down epics and user stories will be a backlog - that is the storage of all tasks that belong to the project.
Note: Remember that a user story is not focused on the functional implementation, but on the value that it provides for the user. Each user story has also a set of acceptance criteria so that a story can be accepted by the stakeholders whenever it’s delivered. It should align with the MVP of your product, as well as with business requirements.
Sprint length
The next important point in preparing the workflow is determining the sprint length. Here we need to take into account the complexity of tasks and the nature of the project. A typical sprint length falls within the range of 1 to 2 weeks, providing a balance between frequent feedback and a manageable workload.
In most cases, a two-week sprint duration is commonly preferred, as it gives a sufficient amount of time to complete tasks while maintaining a relatively fast iteration cycle. This duration also offers more breathing room for the team to address unexpected challenges that might arise during the sprint.
For shorter projects or teams that have more experience working together, a sprint length of one week might be suitable. This shorter sprint duration allows for even faster iterations and can benefit projects with rapidly changing requirements or tight timelines. It also encourages a sense of urgency and frequent communication among team members.
Starting sprint
Up to this very point, almost everything has been settled for you to start off the first sprint. Nevertheless, you still need to make sure that the implementation of your ideas is moving in the right direction. So, here are some important steps to follow at this stage:
Keep prioritizing the tasks. When the requirements have been broken down, prioritize them based on their importance and impact on the MVP; contact the key stakeholders if needed. The rule of thumb is to start with those of the highest priority and difficulty. Sometimes it’s pretty easy to identify the priorities just by looking at the contents of your backlog. For example, for a marketplace application, you would rather first develop a list of products and only then create a shopping cart.
Type | Must have / Should have / Could have |
Priority | High-priority / Second-level / Low-priority |
Size | Large / Middle / Small |
Difficulty | Complex / Mediocre / Easy |
Status | Refined / To be refined |
Assign stories to sprints: Based on the prioritized task list and sprint length, assign tasks to sprints. Try to balance the workload and ensure that each sprint has a mix of tasks that address different aspects of the MVP. Every time you start the sprint, you can adjust the number of stories that can be taken per sprint - sprint velocity
Set sprint goals: For each sprint, set specific, achievable goals that align with the requirements and priorities of the MVP. These goals should be based on the tasks assigned to the sprint. For example: ‘Create a login functionality for the website users’
Conduct sprint planning: Before each sprint, conduct a sprint planning meeting with the development team to review the tasks assigned to the sprint, discuss the sprint goals, and estimate the effort required to complete each task. The most widespread practice is using Scrum poker to figure out the number of points (in terms of difficulty and struggle) each task might cost a team member to complete.
Besides the sprint planning, there are other ceremonies to follow if you’re using agile methodologies and Scrum in particular, like sprint refinements, reviews, and retrospectives. The refinements allow you to come back to your product’s backlog in order to keep the right number of score points for each task and make sure you’re on the same page with other members of the team. In order to evaluate how successful the team is dealing with a workload and motivation, there are sprint reviews and retrospective meetings which can be a fun and interactive way to check what has been done, what the team members struggled with, and what can be changed.
In any case, use whatever is available and working for all of you, as long as everyone is satisfied with the work being done and it’s moving in the pre-defined direction. Good luck with your adventure!