What does it mean to be agile?

Being agile means we know how to react to the market and customers, and we react by responding quickly to their needs and requests. Agile methodologies try to minimize the risk of creating products that do not meet – or no longer meet – the needs of the market nor the customers.
Scrum is one of the most popular agile methodologies that is nowadays used to develop complex products and systems.

Agile scrum methodology is a Sprint-based project management system with the aim of providing the greatest value to stakeholders. It encourages teams to learn from experience, to self organize while working on a problem, and to reflect on their wins and losses in order to continuously improve.

It consists of 3 steps: 
1. getting work done
2. checking it
3. adjusting it

 

We ourselves use Scrum methodology for the management of our own projects, and tools such as Jira, Azure or Trello help us with the project and task organization. They are easy to use, and also let us keep track of the progress, so both we and our clients are always up to date when it comes to work that is currently being done and how its progress is coming along, so that if needed we can adapt to it in the future.

In this post, we will go through some Scrum events and Scrum participants, and what they look like for us.

Sprint

A Sprint is a time-bound period of 2 ,up to 4, weeks during which specific work must be completed and ready to be delivered to the stakeholders. This way, feedback is obtained regularly and plans for further implementation or potential changes can be made.

The duration of the Sprint depends on the size and the complexity of the project itself. Within our projects, it usually lasts for 2 weeks.

Sprint starts with Sprint Planning and ends with Sprint Review and Sprint Retrospective. These phases are repeated throughout the project’s life cycle until the entire project is delivered before the stakeholders.

Product backlog and Refinement

The Product Backlog contains all the work related to product development and its improvement. Product Backlog is a list of work tasks (Task, Story) that need to be done in order to develop the product. This list is open to change and is continuously updated as the work on the product progresses.

Refinement is a meeting in which both the Product Owner and the development team participate. They analyze, discuss, assess the complexity and time needed to complete the tasks. This is also the way of keeping Product Backlog well maintained. Work assignments must be understood by everyone involved (shared understanding), have an estimate on complexity and how much effort (time) will the implementation take.

Refinement and Sprint Planning help us prepare and plan both work tasks and Sprints better.

Sprint Planning

Sprint Planning is the event in Scrum that starts the Sprint. The purpose of Sprint Planning is to define what can be delivered within the Sprint and how will that be done. Sprint planning is done by the Product Owner in cooperation with the entire Dev team.

The estimated duration of Sprint Planning is 2 hours for each week of the Sprint. This means that if the Sprint lasts 2 weeks, this meeting should last 4 hours. But if the team prepares well and estimates the tasks they plan to include in the Sprint, planning can take less time.

Our practice is that Sprint Planning does not last longer than an hour, and we achieve this by carefully preparing and estimating each work task during the Refinement meetings.

Daily meetings

During a Sprint, the team holds daily standup meetings in order to discuss progress and find solutions for challenges we are facing. Both the Development team and Product Owner attend this meeting, although the PO is not required.

During this meeting, all team members should give answers to the following 3 questions:
1. What did you do yesterday?
2. What are you going to do today?
3. Is there something blocking you?

Daily meetings should last from 5, up to 15 minutes.
We hold them every morning, at the beginning of the work day.

Sprint Review

The Sprint Review is an informal meeting during which the team demonstrates what has been achieved, while stakeholders provide feedback. The Development team, Product Owner and Stakeholders are attending this meeting.
The main purpose of the Sprint Review is to examine the outcome of the Sprint, gather feedback from all stakeholders, create a plan and reorganize the Product Backlog.

The Sprint Review is held at the end of the Sprint. The duration of this type of meeting is estimated at 1 hour per Sprint week. This means that if the Sprint lasts 2 weeks, this meeting should last 2 hours.

We like to keep our Sprint Review flexible, therefore our Sprint Review lasts up to an hour.

Sprint Retrospective

At the Retrospective we discuss what went well during the previous Sprint and what can be improved for the next one. We can think of it as a meeting where we discuss the good and bad things that happened in the previous Sprint and the things that we should start, stop and continue doing. This is the moment when the previous Sprint is used for learning.
The meeting is attended by the Development team, Product Owner and Scrum master.

A Sprint Retrospective is held at the end of each Sprint. The estimated duration of the Retrospective is 45 minutes per Sprint week. This means that if the Sprint lasts 2 weeks, the Retrospective should last 1 hour and 30 minutes.

We believe that the time allotted for the Sprint Retrospective should be flexible. When we judge that the Sprint was easy and that we did not have any problems, we reduce the duration of the meeting.

Dev Team

Group of 3 to 9 people that are working together on development of a product, and have all the skills and abilities needed to get the development done.

In our case, a Dev team consists of 1 or more Android developers, 1 or more iOS developers, 2 backend developers (mostly), a designer and a tester.

Conclusion

We have seen what Scrum should look like theoretically, as described in the scrum guide. We also saw how we could apply the Scrum methodology and adapt it to our projects. The Scrum guide should only be a guideline on how to proceed, but the point of agile methodologies is flexibility and learning from previous experiences. That’s why if you, like us, feel that you can’t apply or do some things as described, you have the freedom to adapt them as you see fit for your own team and projects. This will bring out the best in team, as they feel free to express their opinion, approval or disapproval – and in the end, that’s how success is achieved!