After introducing Agile in the previous blog “What is Agile Software development?”, we will talk about how to apply the Scrum framework in your software development company effectively. If you are a company which is about to adopt Scrum then this article is for you!
1. What do you need to know about Scrum?
a. What is Scrum?
It is essential to mention that the philosophy of Agile is all the tasks, whether it’s big or small, all must be completed by a small group of people. As a method developed from Agile, Scrum works the same.
While Agile is an umbrella term used to talk about several software development approaches. In a smaller scale, Scrum is seen as a popular Agile project management framework which helps teams, companies or organizations work more effective in terms of internal/external collaboration and final results by operating projects unit by unit (task, sprint, etc.). The ability to learn from experience and improving the process time after time is what makes Scrum become one of the most adopted sub-set frameworks of Agile.
b. Why we should use Scrum in your software development company?
As if it was only yesterday when there were mere software development companies and technical-related enterprises implementing Scrum in their organization. According to a report in 2018 about Scrum by Scrum Alliance about practicing Scrum worldwide, 94% of respondents use Scrum in their working process. These participants came from many different industries such as advertising, healthcare, education, etc. The expansion of Scrum happens due to its effectiveness and helpfulness which works across industries. Partially, the success of Scrum lies in these six specialties:
- Product quality is optimized as it is developed.
- Your product is improved and updated frequently and continuously.
- Scrum saves you a lot of money.
- Increase transparency across the company.
- Encourage teamwork.
- Get feedback from your client frequently.
For more details, please visit our blog: “Why Scrum is Crucial to your company and pitfalls may happen to your Scrum plan”.
c. Who will be involved in?
A Scrum team consists of three parties:
- Development team: all the task assigned by clients or product owner will be completed by this team. Normally, a newly assembled development team has to go through approximately three sprints to master this framework. A Scrum team will have 3 to 9 members (including business analyst, designer, tester and developer).
- Product owner: This person is the one who has the mission to picture the outcome of each sprint. They will make the best of product backlog and sprint backlog by prioritizing items, estimating workload and time-frame. The product owner must have an insightful view of the product, understand what is in the mind of clients, users or any involved parties.
- Scrum Master: Scrum master will be the one who “creates the balance with the project’s key stakeholders”. In the hope that Scrum team would only focus on their current project, this person will solve any impediments coming across the way, make sure the product backlog is well prepared and ready for the next sprint. Scrum master has to act as a guardian of the Scrum team. They protect the team by limiting tasks sent from clients, project managers, etc. so that team members are able to only concentrate on the happening project.
2. 3 steps to implement Scrum in your process
Rather than going straight to the process of applying Scrum into a project, let’s think about a more familiar activity that we all have to on the weekend: housework.
Step 1: Collect the product backlog — The to-do list. Momma gave you a list of work that you have to do, it includes washing dishes, gardening, washing your clothes, cleaning the house, going to the supermarket.
In Scrum, the list you receive is called a product backlog. This is the board that contains all the inputs from stakeholders: clients, users, product manager, etc. These items may be varied from new requirements for the product, fixing bugs to working on research, etc. in the form of a user story. A standard user story goes like this:
“As a <role>, I want <feature> so that <reason>”
Not only is it essential to define user stories for your Scrum plan at the moment, but your team also has to figure out the time period to complete such a backlog. This time period is called a sprint.
Step 2: Size the user story — A planning meeting will be held so that all three internal parties — the development team, the product owner and the scrum master — have a chance to estimate the time needed to complete every task and prioritize them, the main idea is to exclude irrelevant and unimportant items.
Step 3: Create the sprint backlog — Now what you need to do is gathering those defined (in terms of the time-box and priority) and user stories and put them together in a sprint backlog.
After having decided what user stories to complete in a sprint, the development team will have the responsibility to figure out what moves will be carried out so that a user story could be marked as done.
And now it’s time to get to work.
During a sprint, there are two things you should do:
- Commit to holding a stand-up meeting every day. This activity is to exchange ideas, talk about what is posing obstacles, and what you did in the previous 24 hours. On one hand, the discussion will likely to get feedback from others, solve member’s issues and develop one’s innovation. On the other hand, the whole team will be aware of how the progress is going on and adjust their tasks to fit in the estimated time of a sprint.
- Track and illustrate your process by a burn-down chart. A burn-down chart is a line graph that helps the Scrum team to understand the current progress. Then the team could measure and adjust their work if their performance (the actual work line) is below the ideal work line. Below is the example of a burn-down chart:
At the end of a sprint, the Scrum team should assemble to conduct two last important sessions:
- A sprint review: The common goal of a sprint is to release an increment. Generally, a sprint review is the meeting where the Scrum team and the client will review the product after the sprint. A demo of new features, bugs fixed, new designs, etc. during this session. The development will also present what has been done and what has not after the sprint.
- A retrospective meeting: instead of reviewing the visible outcome of the sprint like what happens in a sprint review session, a retrospective meeting is where the Scrum team, including only the development team, product owner and scrum master, talk about how effective the team is during the sprint. In short, according to Mountain Goat Software, each member has to present some moves that the Scrum team should “stop doing, start doing and continue to do” in the next sprint.
Recently, we at Designveloper has conducted a workshop to introduce Agile and Scrum methodology to our team, you can watch the session here: Agile Development Workshop — Designveloper.
It depends on your team to estimate the user story number which should be included in one sprint. According to Andrew Fuqua, an author from Leading Agile, the time to work on user story has to be no longer than half a sprint and a user story should be completed in 1–3 days. Another thing to remember is that user stories will be accomplished more effectively if they are simple, concise and detailed.
While the sprint backlog discussion is happening, a Scrum team could use Planning Poker technique to estimate the user story. After the product owner, the client or any other person has done the user story describing step, the team will talk about the requirement in detail. Then all the estimators will show their grade of the user story via a card. This grade is called a story point, and the team will prioritize user stories by their points.
Hopefully, you had a better understanding of Scrum after reading this article by Designveloper. And if you are looking for a software development company to work on your future product, let’s take a look at some of Designveloper’s projects, we are using Scrum in our process to optimize results and every product too!