Open in app

Sign up

Sign in

Write

Sign up

Sign in

Agile Scrum framework guide and the breakdown of the value proposition, best practices and useful tips

Aharon Rossano
Aharon Rossano
Published in
8 min readSep 28, 2017

--

This is my understanding and interpretation of Scrum. Over the years I’ve built teams and helped teams find the most efficient way to operate. Being an extremely pragmatic person, I invest a lot of time and energy into efficiency and productivity. I find scrum to be extremely beneficial making the team more collaborative and dynamic. I’ve noticed that each team and organisation has their own flavour of Scrum. It’s generally criticised as bad practice, but I think it’s okay as long as the actual value is still there. This is why a big part of the article is focused on ensuring you understand what the value of each part is.

I kept the article in bullet format so it’s easier to come back to. I’m not sure it is all going to make sense if you had never heard of Scrum, it might be worth having a quick read of another intro article before reading this one.

Introduction to Scrum

What’s the difference between waterfall and agile?

  • Waterfall methodology: linear and fixed. Scope, plan and estimate the whole project.
    Best to use when the project is fixed; outcome, deadline, budget, resources etc.
  • Agile methodology: break deliveries into small sprints and pivot as you go.
    Best to use when you’re open to exploring, and the project outcome is dynamic;

Scrum provides answers to a few fundemntal problems we have with traditional team and project management

  • We are bad at estimating time, but better at rating difficulty proportionally.
  • It’s extremely hard and sometimes impossible to plan a whole project in advance. Technology products are very dynamic and require exploring and problem solving as you go.
  • It’s easier to define high level stories than it is to capture all the tasks.
  • Productivity should be measured as a team and not as individuals. It improves collaboration and overall performance.
  • Providing transparency across the team helps avoid any blockers.
  • Assists with flattening the hierarchy.

Basic principles

  • Terminology: Scrum is not a methodology. It simply provides structure, discipline and a framework for Agile development.
  • Epic — collection of stories. (similar to projects)
  • Story — instead of describing a task, you describe a problem or a journey. (e.g user can search articles) (similar to tasks)
  • Sprint length: 1–2 weeks. I prefer 1 week sprints, unless it’s hard to deliver results in a week and then 2 weeks. (e.g part time employees or projects, complex tasks etc.)
  • Difficulty ratings: ?, 0, 0.5, 1, 2, 3, 5, 8, 13, 21. Over time as you get better at estimating difficulty this helps with measuring velocity.

Sprint start

Pre sprint planning (individual)

  • Clear completed tickets from Current Sprint Board to the Done list.
  • Review remaining tickets from last week. Complex tickets that have stayed for more than 2 weeks need to be revisited, so that the board stays relevant. You can break it to smaller tickets, or reprioritised and put it back to the backlog, etc.
  • Set yourself and the team a list of goals for the week that you can share with the team during the sprint plan.

Sprint planning (group)

  • Takes about 1–2 hours.
  • Run through projects and goals and define what the goal is for this week so that the sprint tickets reflects it.
  • Break goals into epics and stories and define who is accountable for the ticket and highlight who wants or needs to be involved to help.
  • Go through backlog and see what tickets need to be moved into the sprint.
  • Start the sprint.

Sprint plan tips

  • Build a high level roadmap or quarterly plan and use it as a guideline so you still have some direction. That helps build your epics.
  • Having a broad idea of timeline can help create a feeling of urgency and push the team to move faster. You want to balance between compromising on quality for time and money.
  • Prioritise goals by what’s most important and avoid over cluttering with too many, so you can push through the week to a get something done.
  • Don’t over populate your ticket management system (e.g Asana / Jira). As you keep pivoting tickets will become irrelevant and then you double handle adding and removing tickets.

Daily

Daily standup (check-in)

  • Takes about 1–2 minutes per person.
  • Go around each person and discuss: what you’re working on today, progress, any blockers and issues with reaching weekly goals. Remind everyone how it’s connected to the weekly goal.

Daily checkout

  • Keep basic notes of your progress through the day (I use notes app or markup editor) for checkout on instant messaging or tomorrow’s standup. (e.g finished login page)

Daily general

  • Add tickets to backlog as you go along for new things that come up. Only if something is urgent it can go into the sprint and team needs to be aware.

Standup tips

  • Stand up improves accountability and focus on setting intentions for the day. It’s important to be consistent, on time and have full presence.
  • If everyone cannot get together for stand up (check in/ check out) then write on instant messaging (e.g slack channel: #daily-check-in)
  • If you have a global team it’s a bit harder to sync times. The end of the day standup which is the start for the other team works fine. Make sure you keep instant messaging check in and check out messages, it gives you a good idea to what the status is when you get started and the other team had finished.
  • If a manager doesn’t turn up, and the team feels it’s pointless to have a standup. You’re probably doing it wrong because only the manager is able to connect the dots and make sense of what everyone else is saying. I believe accountability should be shared across the team and so everyone should take interest to what others are doing.
  • If it takes longer than 2mins per person, it is highly possible the team hasn’t prepared, you can set a reminder using a bot on instant messaging 15mins to prepare and 5mins to attend. If it’s because of problem solving during the standup, suggest to do it afterwards so the whole team doesn’t have to stay.

End of week — Retrospect (weekly wrap)

Pre retro planning (individual)

  • Move finished ticket to done list.
  • Take notes on status update through the week. Keep notes aligned to goals.

Retro (group)

  • Takes about 1–2 hours.
  • Status update on all goals and epics.
  • Optional: you can combine the update with weekly demos — it’s great to share and show results at the end of the week, it also means everyone is working towards a delivery.
  • Reflect on how the week and tickets went: what went well and what didn’t, time leaks, surprises, wins and loses etc.

Retro tips

  • Be honest during retrospect, the team can then try to help with how to improve.
  • Be kind and constructive with feedback. It’s important because you want to encourage everyone to feel comfortable to share.
  • If you use Trello, you need to manage archiving. You can either duplicate your done list and put a date into it, or move the whole list into an archive board.

Scrum Master

The scrum master responsibility is to help with managing the process described above and help with unblocking. During the standup meetings the Scrum Master can help facilitate the meeting and make sure everyone is on time.

I personally think it’s important that it is one of the actual team members who takes this responsibility and not someone who is solely acting as a project manager. That means the knowledge stays within the team and keeps the team lean and efficient.

The scrum master responsibility can shift between team members over time, it doesn’t have to be the same person forever, and I actually recommend it. It’s very similar to sitting at the passenger sit or sitting behind the wheel and driving. You remember the way better and are more alert. I also think it reduces the tension when the manager is not acting as the Scrum Master.

Scrum board

You can setup a scrum board on your preferred task management platform e.g Trello, Asana, Jira, Pivotal Tracker etc. or use paper notes.

A story goes through the following stages / lists.

Board — current sprint (sample board on Trello: https://trello.com/b/tB1Ek8cb/scrum-board )

  • Backlog
  • Next
  • In Progress
  • Staged / Drafted
  • Approved
  • Done

Optional lists: testing, icebox (another level of backlog to burry items even further).

You may have a different process that you want to capture and so you may want to adjust it all together.

Archiving is important so you can measure your progress over time. Some platforms provide better functionality than others.

It’s recommended to put up the board somewhere everyone can see. So if it’s a digital one, it can be projected on a digital screen or show some stats of the team’s performance.

General tips

  • Don’t use scrum because it’s trendy. Use it because it fits the way you want your team to operate.
  • It’s recommended to keep teams between 6–10 people (size of team that 2 large pizzas can feed).
  • Adjust the process based on the team size. Sometimes bringing multiple teams makes sense and the size grows to about 20–30. Then you might want to have each group show a single demo rather than everything they have done this week.
  • If the point system works for you over time, try to see what you can do to increase the number of points to make the weeks more efficient.
  • Put as many points on the board as a team, not as individuals.
  • It’s okay to be reactive under specific circumstances. You generally want to aim for consistency and try to finish off the sprint, but that won’t always be possible. If it happens all the time you may have a problem with planning or the nature of the business requires it and you need to plan ahead for it. Meaning you may not want to plan to full capacity.
  • It’s okay to have different multiple projects running in same team as long as you’re open to collaboration.
  • If you think you don’t have time to meet in a small team, you probably still don’t understand the value. Try starting with small steps with instant messaging standups and slowly experiment adding the rest.

Extras & Collaboration tools

Project management software

Instant messaging

White board

Wiki

Notes

Insight management sharing

***

Please share this with all your friends and hit that ♥ button below to spread it around even more. Also I’d love to hear if you have any tips or tools you would like to share in the comments section!

***

Agile
Scrum
Team
Digital Transformation
Collaboration

--

--

Aharon Rossano
Aharon Rossano
Follow

Written by Aharon Rossano

119 Followers

Senior Solution Architect with IBM Client Engineering. All my opinions are my own and do not represent those of IBM

Follow

Help

Status

About

Careers

Blog

Privacy

Terms

Text to speech

Teams