SCRUM: The ultimate 15 minutes guide with pictures
Hi, everyone! Long story short, I was combining working as an Android developer and Scrum Master for 2 years and it was quite a great experience. Being a scrum master feels really different when you are a team member, especially developer. It literally forces you to get the essence of agile. Now I want to share obtained knowledge with community.
This will be an article about scrum, super easy and with a lot of pictures.
Let’s go!
First things first. What is agile? It is an iterative and incremental development methodology, that encourages flexibility, efficiency and self-organization in work.
And what is scrum? It is a framework based on agile principles and values, it provides some concrete methods for efficient and creative product development.
This picture can help you to understand the main difference between common, so-called “waterfall” approach and agile. Please note, that it’s not a guide on how to develop a product in agile!
If your project is quite large and the market is constantly changing, you have to be flexible to stay alive, cause you just don’t have time for a full waterfall cycle. That’s why agile is popular in IT area — IT is developing too fast and you can not afford the luxury to write docs for several months.
Let’s get familiar with the basic terms in scrum. First will be the roles:
These are scrum artifacts:
So, product backlog contains all the tasks for your product. Team takes the most essential items from product backlog to sprint backlog and makes them during sprint. Tasks should be chosen in a way to have product increment in the end — something valuable for the product, a feature that your client can already use.
Now is the right timing to talk about sprint. What is it? It is a short time period during which the team does all the tasks in order to get a product increment at the end.
Usually, sprint length is 2 weeks or 1 month, but you can adjust it to your needs. For instance, I had a 3-weeks sprint in my previous team, and I knew a team, that was working best with a 1-week sprint. Just remember that the period should be short enough, preferably no longer than 1 month.
The next picture is super important, but also super hard. It is about process.
Now let’s deal with everything happening here:
On sprint planning team takes tasks from product backlog to sprint backlog. During sprint team makes these tasks, having daily scrum each day to make sure everyone is on the right way.
At the end of the sprint product increment is shown on sprint review and now being ready to be shipped on production. After that team members discuss previous problems and suggest improvements on sprint retrospective.
Then new sprint planning opens new sprint. We’ve come to full circle.
As you can see, there is also an arrow on product backlog rectangle. It demonstrates the fact, that team is constantly working on backlog during product backlog refinement.
For now, let’s get back to agile and speak more about its values and principles. So, this picture shows 4 main agile values:
And this one — 12 agile principles:
I don’t want to go deeper on those pictures, cause I think it is enough information on them for you to catch the essence.
Another important picture is about 5 people values, that scrum is enlightening:
I love this one. Its main message is “Just be conscious, man!”
I suppose you already get the fact, that there are a lot of meetings in scrum.
But I don’t think you want to lose your time and sit pointlessly on them. I think you want them to be as quick and efficient as possible, especially if you are a developer. Why? Because we usually want to spend more time coding than talking and we usually want to have a clear understanding of future tasks with technical details and corner cases.
Pictures below show input, output and the most valuable information for each scrum meeting. You just have to be sure, that your team follows these recommendations (not as easy as it seems, I know).
1 meeting = 1 picture:
There are several more important concepts worth mention. And first will be story points.
Story point is a tool for relative estimation. It estimates the effort to make a task done from 3 points: time, complexity and uncertainty. So, story point is not equal time! Time is not relative, because it is specific for each team member. Look at this picture to understand the difference better:
The measurement can be done in Fibonacci sequence 1, 2, 3, 5, 8… or in T-Shirt sizes S, M, L, XL… We use these systems because they are convenient for prioritization — the difference between 8 and 13 is significant and makes your prioritizing choice easier.
Nice tip where to start with your first story point: remember the easiest, fastest and clearest feature/task, that your team has made. That will be your team “1sp”.
The next important concept is user story.
It is a short and clear description of feature, that will give user (minimal) real value. Some functionality, that may be quite small, but already “touchable” and needed by the user.
Even though I’m not a fan of acronyms, I find this picture really useful to better understand the main qualities of user story:
Hierarchy tip: general vision -> epics -> stories -> tasks
This one will make it clearer:
I will now step on a slippy road, but as a developer, I can’t help but mention technical debt. It seems like there is no room for it in all these user stories, MVP and features concepts.
If somebody is trying to convince you that technical debt is not ‘scrummish’, just remember that there is no one word about technical debt in Scrum Guide. So this part of your team processes is completely on each member's consciousness (do you remember 5 people values?).
I think it is essential to spend 10–20% of sprint capacity on refactoring and bug fixes. And I also think that bugs and tasks for refactoring should be separate from user stories, although in the same place in the hierarchy.
Let’s take a quick look at the remaining definitions:
Burndown chart is a line chart drawn between remaining work and time. It is very helpful for tracking team progress as it “burns through” tasks in a sprint. It is only an analysis tool, not suitable for reports or work evaluation!
Velocity is an average team performance in story points based on previous sprints statistics.
Capacity is future team performance in story points based on the team’s availability — there may be an extra holiday next sprint or someone will go on vacation.
They both are made to make your planning easier and clearer.
DOR or Definition of ready and DOD or Definition of Done are the checklists useful for understanding the work direction.
If the story meets DOR, then it can be taken in the sprint.
If the story meets DOD, then it is ready for release.
Jira (paid) and Trello (free) are project management software well suited for agile concepts. It will take another several articles to explain in detail how these software work, so not today.
Just remember, that it’s not just about ‘cards moving on board’, with proper setup and a little knowledge of programming it’s a very powerful tool for your work.
That’s all for now. I made this guide because I really missed having all the information in one place, after all even the official Scrum Guide is not full enough. Hope it turned out to be useful for you and your knowledge became a little more ordered!
Do not be afraid to contact me anytime with feedback or questions https://twitter.com/YCoenova
