Scrum 101: a practical guide to boost your team’s productivity

We know it: your team’s new year’s resolution involves being more productive and precise, increasing the quality of your deliverables but without compromising efficiency. But we also know that (as with many resolutions), it’s much easier said than done. At Good Rebels our teams have the freedom to select the methodologies that best work for them. Lately, agile methodologies have stood out as one of the preferred frameworks amongs Rebels, and we have already implemented them in many of our teams. 

But this is not just another post about the joys of agile and its different methods. This is about how we (more specifically, some of our design teams) work using agile frameworks, and how you can start to implement them into your teams as well. 

Frameworks allow us to standardise processes among the different teams, and between the teams and the client, in order to work more efficiently, increase our productivity, minimise errors and improve performance. In other words, they make life easier for everyone working in projects involving various stakeholders, which is the case for digital product design and development. 

Scrum is one of the most widely used frameworks in agile methodologies. At Good Rebels, we are offering you the key to successfully incorporate it into your processes: the importance of proper planning, the meaning of user stories and the most important rituals. Keep reading to learn more! 

Why Scrum?

Before we start, let’s highlight some of the advantages of working in Scrum:

• Cooperation. Communication is constant between all project stakeholders, so the client and the team are always aligned, thus saving everyone time and improving overall team management and coordination. 
• Productivity. By improving communication between the client and the project team, we are able to increase the productivity of all the parties involved.
• The client is part of the team. The client is always present throughout the process, working in alignment with the team, towards the same goal and following the same delivery calendar, so there are no surprises. The result is a happy client who has access to real time information about the project.
• Flexibility. Sprints having a set duration allows us to evaluate the product’s priorities in real time according to the market or to users’ needs. It’s crucial to take into account that changes are normal in any digital product design and development project, and thanks to working with Scrum it is much easier to plan an interaction, eliminate a feature or suggest a new one.

Sprints and user stories in Scrum

We have already mentioned our projects involve several teams with different areas of expertise, as well as clients whose needs we must meet and who we must keep updated at all times. 

Planning and organisation are key, and that’s why we need specific profiles to set some guidelines for the team. These strategic profiles are responsible for defining the objectives and future functionalities of each project, as well as for planning the time allocated for each task or assessing the team’s workload.

If we take into consideration that digital products are constantly evolving and the design and development process can last years… you’ll agree with me when we say it’s not possible to plan all the above with a long term approach. Digital products are often subject to users’ requests or complaints, and they usually need to be updated to incorporate improvements or new features. 

That’s why Sprints are a crucial part of Scrum. These mini-projects have a set duration (of generally,  two weeks) and are aimed at adding value to the product. At the beginning of every sprint, the team should establish a tangible objective, which they should meet by the end of the sprint in one way or another.

This is an example of how a sprint can be defined:

In this context, user stories are a very powerful tool for defining sprint objectives when designing and developing digital products. 

What are user stories?

User stories are descriptions of a feature: they define a functionality of the software we are developing using a simple language which is familiar to the user and the client.

In order for all team members to understand the scope of a user story, they must be precise. It is, in other words, a strategic need that must be addressed during the given sprint. 

Who creates user stories?

Anyone involved in the project can write a user story, which gives them increased value due to the plurality of points of view. If the responsibility for creating user stories was centralised in a single team member, some of them could leave users’ point of view aside, increasing the dependence of the team on a specific person. 

However, even if all team members can write user stories, it is the responsibility of the Product Owner to organise and prioritise them. 

What’s their structure?

A common structure for user stories is the following: 

As [user] +  I want [intention] + For [goal, achievement]

Let’s see an example, keeping in mind that we must use users’ language, not designers’.  So, imagine that we are a greengrocer and are willing to improve sales through our website:

As a I want to to [ increase my profit].

By using this structure, it is easier to know what the user really wants and how we can improve their experience. In addition, they allow us to get closer to the client: since they are aware of what is being built at all times, and they can assess whether the work lives up to their expectations. 

Some Scrum rituals

As in any other project, all the teams involved in the design and development of a digital product are connected by some project management tool such as email or some other communication platform. 

However, to really carry out a project in Scrum, a series of rituals  are needed. Rituals allow us to improve communication between all the teams, including the client team, and give us visibility of what’s on everyone else’s plate, at all times. 

Some of the most important Scrum rituals are the following:

• Sprint Planning. It takes place at the beginning of every sprint, usually every two weeks. Sprint planning brings all the teams together, including the client, to agree on the sprint’s objectives and on which user stories are going to be addressed. The user stories that have already been identified but have not yet been assigned to a sprint are collected in a list called Product Backlog.
• Grooming. This takes place every 1 to 2 weeks. It involves all the teams and the main objective is to refine the Product Backlog. In other words, see which user stories are listed, prioritise them and define some of them further or even eliminate some. 
• Daily. These are daily meetings held internally by each team. They last about 15 minutes and their aim is to keep everyone  informed of what everyone else did the day before, what they are going to do today and whether they have encountered any stoppers. When stoppers appear, usually a separate meeting is scheduled to address them. 
• Sprint Review. At the end of a Sprint, the team and the client usually meet to review what has been developed and finished during the past (normally) two weeks. This meeting is often used to start planning for the next sprint, as it assesses what is pending from the previous sprint, what could be improved or the difficulties the team has encountered. 
•  

Planning and tools

We have already mentioned that these are highly complex projects, mainly because many different variables come into place. One of those variables is the variety of teams involved in the process, whose expertise ranges from design to development and whose methodologies and ways of working often differ. In order to handle this dichotomy, we have adopted a hybrid methodology: Dual-Track Scrum. 

When working in Scrum, one of the simplest ways of organising (and simplifying) the work is to divide tasks into separate boards where user stories and other tasks are collected. This ensures the correct planning and organisation of the team, thus reducing the dichotomy we mentioned earlier. 

Next we will see some examples of  two of the project management tools that we use in the Good Rebels design team. . 

Teamwork

This project management tool includes all the teams involved in the project, including the client who, besides using it to get a general overview of the project, can actively participate. 

This is where each sprint is structured and user stories are created and assigned to a specific team or person. It also allows teams to estimate the time required for each task, as well as to allocate working hours. 

To structure each sprint in a visual way, an agile board or a sprint board is set up and organised in columns. These columns contain the user stories which, as we can see in the image, are represented in the form of cards.

Normally, the column in which the user story is collected indicates which team is in charge of carrying it out.

Columns involving the development team:

• To do. Collect the user stories that must be carried out in this sprint.
• Doing. Collect the user stories that are being developed at that specific moment.
• Resolved. Collect the user stories that have already been developed and are ready for review.
• Code Review. Collect the user stories under review. The team has to review the code and improve its quality if necessary.
• Blocked. Gathers the user stories blocked due to errors, lack of context, legal issues…
• Ready to test. Collect the user stories in which the code complies with the standards for the QA (quality) team to review.
• Testing. Before the user sees the new functionalities, changes or updates, they are tested in a fictitious environment in order to avoid future errors.
• Done. Completed user stories. Users can now enjoy the new functionality, change or update. We could say that this is the end of the development team’s work.

Columns involving the design team: 

• DoR (Definition of ready). Collects user stories that have already been designed, validated and estimated. They are ready to be developed.
• Grooming. Collects user stories that need to be reviewed, validated and estimated. It is usual to assess whether they will be part of the next sprint.
• Doing (GR). Collect the user stories that are being designed.
•  

The logical order would be for these last columns (Designs and flows, Doing (GR), Grooming and DoR) to be placed first, since before a user story goes to development it has to be designed, reviewed and validated. However, this board is focused on development work, so it is prioritised and organised for the development team.

Trello

Just like Teamwork, Trello is a project management tool but, in this case, it is only used by the design team. This is where we organise ourselves internally. The team lead, who has a key role in terms of management and organisation, reviews all the user stories assigned to the team in the Teamwork dashboard and then transfers them to Trello, transforming them into a language closer to design. No matter how good the communication with the development team is, user stories have to be adapted, understood, and organised according to our criteria and our way of working. We also need this board to attach references or add comments between us. Trello also follows the agile dashboard column structure, although it is different from Teamwork’s:

• Docs. Supporting documents that help us in our day to day, whether functional, instructional, containing access credentials, etc. 
• Backlog. Equivalent to the Designs and flows column in the Teamwork dashboard, it collects the user stories that are going to be designed in the future, without specific priority.
• To do. Collects the user stories that must be designed.

• Doing. Collects the user stories that are currently being designed.
• To review. Collects the user stories that have already been designed and need to be reviewed and validated by the development team and/or the client. 
• Blocked. As in the Teamwork dashboard, it collects the user stories blocked due to errors, lack of context, legal issues…

• Grooming. As in the Teamwork dashboard, it collects the user stories that need to be reviewed, validated and estimated. It is usual to assess whether they will be part of the next sprint.
• DoR. As in the Teamwork dashboard, it collects the user stories that have already been designed, validated and estimated. They are ready to be developed.
• Implemented. Equivalent to Done in the Teamwork dashboard, these are completed user stories; users can now enjoy the new functionality, change or update. 
• Mastered. Collects user stories that have been integrated into an internal document called Master, allowing the team to have a snapshot of the current state of the product. It is the last step for us as a design team. 

Thanks to this structure we know who is working on what at all times, what has been approved by the development team and/or the client, what is being developed and what has already been launched.

Beyond digital product design and development 

Scrum is a methodology that facilitates multidisciplinary team management, task distribution and client supervision. However, even though it was born as a framework for software development and its use is widespread in design projects, you may be wondering… can we apply it to other types of projects? 

The answer is yes: at Good Rebels we apply the Scrum methodology in other areas, depending on the type of project. And although it requires a detailed analysis of the project’s functions and implementation, nothing is stopping us from experimenting, taking some stuff from here and there and seeing what happens.  

There may be projects where we can use Scrum at 100%, but for others we may only be able to apply 50% of it, or even 10%. We may even need to come up with our own customised version  of Scrum. It is a matter of testing, making the framework work for our project. 

Thanks for reading! If you wish to know more… let’s talk?