If you are a junior professional afraid of “scrum experience needed”, fear no more
Scrum basics for young professionals feeling lost in the wild.
Besides needing 15 years of working experience in your 20s and knowing how to code in medieval Icelandic, employers are now requiring that you are familiar with scrum — an agile methodology that’s not even a methodology in the first place.
I know well how that feels: not long ago I was struggling to become a full-time UX designer and reading “scrum experienced required” everywhere only made everything harder. “So I need management experience now?!”
Still, I read so much about it that I became a professional scrum impostor (dear manager, if you are reading this, I must confess I became a UX designer the moment we met. It was magical!) and managed to land a great job regardless of clearly not knowing what I was talking about.
Why did he hire me? Probably because agile experience becomes irrelevant if you fill the other requirements: scrum is very complex on a management level, but mostly a board with deadlines for everyone below it.
I’ll now share with you how it is like to work under scrum management and provide you with some tips that will help you talk back when agile is mentioned! :)
Have you any doubts as you read, leave a comment and I’ll answer + edit the article to make things clearer.
What is scrum?
Scrum is a framework that emphasises autonomy, teamwork, and an empirical process for achieving well-defined goals— and here we have another useless definition, huh?
First, let’s talk about agile autonomy
If you’ve ever been a freelancer / entrepreneur, you already scrum by heart. Autonomy implies there will be no manager to give you plans on how your work must be done and no one but you will be responsible for your failures.
Whenever a task is added to a sprint (~2-week period that we set to address some tasks), designers and developers are on their own to find the best possible solution — meaning managers will give you nothing but demands.
That doesn’t mean a junior designer would be left to drown in tears in front of his Mac, but that management assistance will go before long so you must develop a taste for autonomy.
So what the hell is a framework?
We all feel an urge to call scrum a methodology, but that certainly isn’t the case. A framework is a set of tools you get to perform some job, just like a hammer allows you to hang a picture, build a house, or even hit an HR professional demanding excessive requirements.
Let’s go through the 4 Values of the Agile Manifesto so you can better understand how scrum works:
- Individuals and interactions over processes and tools.
- Working software (or project) over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
So you just learned that there are no plans when working with scrum and that we follow no processes at all. We all work in straight jackets when scrumming!
Except for the straight jackets, you‘d be wrong. What we mean is that markets are unpredictable by nature and that changes happen so fast that your plans (and possibly your company) can be taken down in no time — thus, processes and plans are better used to indicate the way instead of being the only road.
It also means that all of scrum roles and rules are adapted from company to company and from worker to worker, therefore it’s impossible to predict how working under scrum in a given company would be before being hired there.
Visit 100 companies and you’ll find 101 ways to do scrum in the wild .
I just made that phrase up but any scrum master (a professional solely responsible for making scrum work) would agree with me, so here’s a piece of good advice: learn the basics (right below) just so you won’t be dumbfounded when you finally have to face it. I promise there’s a good chance your team won’t notice your lack of experience just like mine wasn’t.
The scrum process in a nutshell
This diagram may seem daunting at first but here comes good news straight from the Scrum Guide: “Scrum is a framework that is easy to learn but difficult to master”. (And mastering it is your scrum master’s job, not yours!)
Now let’s talk about each step of this diagram, starting by the backlog.
What is the product backlog?
The backlog is a collection of user stories — things you audience/users need — that you and your autonomous team (also known as squad or scrum team) will eventually work on.
By autonomous, I mean REALLY autonomous: stories are not tasks* but needs (“I need to get my products faster” rather than “develop store pick-up module”), implying you will not only have to build its solution but to plan the best possible solution for it. (Hence the importance of a good portfolio, proving that your manager won’t need to helicopter-hover you.)
* I told you scrum comes in different shapes in the wild, so I must tell you that stories are tasks in many companies. The only thing I can assure you is that working by yourself is mandatory regardless of your backlog’s composition.
Now this may remind you of Trello but there’s a huge difference here: since we work in sprints, the backlog is for reference rather than a constant concern for the squad. Your real worries will be brought about during the Planning.
What is Sprint Planning?
It’s a ~2-hour meeting in which your Product Owner (or Manager) will say what has to be done in the next sprint.
Now, remember what I said about teamwork and collaboration above else? The owner / manager will raise his most pressing concerns but the squad also has a strong voice in this meeting — and that’s exactly why you need a few hours to define the next sprint.
You may notice that your manager’s requests no longer make sense or that it would be wildly effortful to make, so you and your teammates will manicure his solutions or maybe even discard it.
Whatever the outcome, the worst of all comes immediately next…
The grinder of juniors; the scourge of interns; the manager’s whip — also known as Story Points.
Oh, those f* points. What are story points?
Go to 100 companies and you’ll find 101 species of story estimates. Seriously, don’t even waste your time digging it further than the text below.
In sum, story points are effort estimations one must assign to whatever they must do during the sprint — meaning the sprint planning won’t be over until the squad has a reasonable amount of points to work on.
Did you notice I said “EFFORT”, not “time” estimations? That’s why story points suck at the beginning: you will have no idea of how to estimate your work in points, limiting yourself to a good-old “I think that takes x hours…”
But here goes some good news about story points: you’ll have a team and a scrum master to help you make estimates. Also, story points are limited so you are forced to split stories when they get too big, meaning you can assign a couple of points to everything before trying bigger estimates.
But why points rather than time? Because stating effort makes it clear for everyone how hard something is rather than how long it supposedly takes — which is great since no one will be able to say “but you promised me 2 days” when one of your deliveries fail.
And from that comes the Sprint Backlog
Now that your squad discussed what had to be done and even assigned nonsensical points to it, it’s time to close your planning with a set of stories you have to get solved.
Every task amounting to a reasonable amount of points will go into the sprint backlog, which is a short period (usually two weeks, but it can go from 1 to 4 [I told you it’s just a framework!]) in which you must deliver useful / valuable solutions to all your assigned stories.
Now, remember that “scrum is…for achieving well-defined goals”? It’s crucial that your sprint has a single sprint goal, which is some task your squad must address no matter what because — although I forgot to tell you —those absent managers will remember you name if you have nothing valuable to give them after 2 weeks.
That doesn’t mean you’ll have a single task during a sprint, but that its goal is your highest priority and you have the right to ditch everything else if you feel the sprint goal is threatened by it.
Now your sprint has started!
Individuals and interactions over processes and tools; working project over documentation. Remember that and good luck!
At this point, you can start applying Design Thinking techniques and such so you find the best way to address a user story. Creatives will be horsing around Pinterest whereas developers will be copying code from Stack Overflow — both equally desperate, but projecting confidence all the time.
The good news is that you’ll be able to cry to one another every 24 hours during an event we call the Daily Scrum.
What is the Daily Scrum?
The daily scrum is a 15-minute meeting for the squad to show what they have done in the last 24 hours and what they plan to do up to the next daily.
Remember the scrum master? This guy will be in command here to clear any doubts, align expectations, and get rid of impediments — which is how we call anything hindering your work.
That doesn’t mean you cannot ask for help during the other 23:45 hours of your day, but that it is a great opportunity to make your concerns heard and ensure everybody is treading the same path. Here’s an example:
Designers often plan extravagant solutions that are not viable for developers, so presenting it during a daily will prevent you from working 2 weeks on something that can’t be produced.
“But should I always wait until the daily to get help?”
Of course not! For that, you’ll need some good reasoning: is your sprint goal at risk? Is there are a good chance the product owner will whip you for waiting? If so, then you should act immediately; if not, you’d better wait so you won’t hinder anyone’s work.
Finishing, we have reviews and retros
You have already read a lot, so I’ll make things simpler: a told you scrum is an empirical process and, for that to work, it needs constant evaluation so everybody learns from past mistakes, as seen below:
The Sprint Review is a meeting to discuss what has been delivered and also to present solutions to stakeholders and others. This is NOT a status report, but an opportunity to gather feedback and improve collaboration.
The Sprint Retrospective often follows the review (so we are talking about a 3-hour meeting now) in which the team will discuss the process. You’ll discuss point estimation; shallow story descriptions; stakeholders impositions, etc.
And that’s it, scrum is that simple and you could even apply it to your home as I did when freelancing. Make a Jira account and get familiar with it!
Seeking a mentor?
Starting a new career is not easy: our lack of experience is hit by an insurmountable wave of content that makes us feel like we need to memorise an encyclopaedia before working. It’s an awful feeling, I know.
I’m no mentor, but having accomplished a thing or two as a designer, writer, and digital marketer (and now working as a product designer at fashion giant), I know a thing or two about career shifts in order to aid you.
How about you follow me here or connect with me on LinkedIn so we can take this conversation forward? I’ll be happy to provide you with any assistance you might need! : )
