Thread by @YCoenova, For 2 years I was 80% Android dev and 20% scrum master. [...]

For 2 years I was 80% Android dev and 20% scrum master. It was enough for me to get the essence of agile (at least I think so). Now I want to share knowledge with community.
So, this will be the thread about SCRUM, super easy and with a lot of pictures. Let's go!
#Scrum #agile

First things first.
What is AGILE? It is iterative and incremental development methodology, that encourage flexibility, efficiency and self-organization in work.

And what is SCRUM? It is 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 main difference between common, so called "waterfall" approach and agile. Just look at it!

If your project is quite large and market is constantly changing, you have to be flexible to stay alive, cause you just don't have time for full waterfall cycle. That's why agile is popular in IT - it is developing too fast and you can't afford the luxury to write docs for months

Another guess why agile is populat in IT - because in IT people make money from air and that's why they have an opportunity to waste it on some suspicious ideas like agile

Let's get familiar with 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 the way to have product increment in the end - something valuable for product

Now is right timing to talk about SPRINT. What is it? It is 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, but you can adjust it to your needs. For instance, I had 3-weeks sprint in my previous team, and I knew a team, that was working best with 1-week sprint. Just remeber that the period should be short enough, preferably no longer than 1 month.

Next picture is super important, but also super hard. It is about PROCESS:

Now let's deal with everything happening on this picture, open it and follow my lead.

On sprint planning team takes tasks from product backlog to sprint backlog. During sprint team makes these tasks, having daily scrum (or stand up) each day to make sure everyone is on the right way.

In the end of the sprint product increment is shown on sprint review (or demo) 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 on product backlog refinement (or grooming).

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 essense. Okay, there is a lot of information on them, it will be great if somebody just read all this stuff

Have you already get bored with all this "N super important things" pictures? Don't be! Because another picture is coming. And it is about 5 people values, that scrum is enlightening.

I love this one. It's main message is "Just be conscious, man!"

I suppose you already get the fact, that there are a lot 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.
That's why I made these pictures on each meeting, showing INPUT, OUTPUT and the most valuable information.

1 meeting = 1 picture. Let's go!

Sprint Planning

Daily/Daily Scrum/DSM/Stand Up

Demo/Sprint Review/Demonstration

Sprint Retrospective/Retro

Grooming/PBR/Refinement

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 task done from 3 points: time, complexity and uncertainty. So, story point != time! Time is not relative, because it is specific for each team member. Look at this picture to understand the difference:

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 - 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 most easiest, fastes and clearest feature/task, that your team has made. That will be your team "1sp"!

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 concept 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 consciousness (do you still remeber 5 people values?

).

I think it is essential to spent 10-20% of sprint capacity on refactoring and bug fixes.
And I personally also think that bugs and tasks for refactoring should be separate from user stories, although in the same place in hierarchy.

Latest Threads Unrolled: