A typical sprint

If you’ve ever worked in a tech company, the following words might be true to your experiences. If you haven’t worked in a tech company and wonder what your average programmer does with his time at work, here’s a satirical view of a sprint. A sprint is a defined period of time of work, with a usual length of two weeks.

A sprint usually starts on Monday, with what is known as a sprint planning meeting, where a team decides what they will be working on in the next two weeks. If you’re a hopeless optimist like me, you’d think this should take no more than 2 hours, 3 tops. However, reality is about to kick in shortly. So, after everybody is in the meeting room and you finally manage to establish a connection with a peer from the client side (which usually takes about 15 minutes, added to the about 10 you’ve already lost while trying to connect the damn laptop to the TV), the fun begins. During this meeting, you’ll notice a series of…let’s call them happenings:

  • that user story that no one knows nothing about, yet on which you’ll dwell on endlessly for 20 minutes with no defined result and to which you’ll have to “get back to someone on it”
  • that one person who doesn’t pay attention to a god damn thing and when the time comes for him or her to give his or her estimation on story points, he or she requires a rundown of everything that was discussed up until that point
  • the same person as above for the next 10 user stories
  • the insufferable and unending discussions about the right amount of story points you should give to the current user story (which usually occurs for about 3 or four user stories)
  • and finally, while all this is going on, you begin to wonder why you’re there, if there is a goal to all of this, and how your life would have looked like if you decided to become a lead singer and try to become as good as Freddie Mercury

The end result of all of this is of course is a vaguely defined backlog from which everyone sort of knows what the f**k they’re supposed to be doing, a meeting which lasted 1.5 hours more than it was decided or needed and a bunch of hungry people because of course, the meeting lasted way into what should have been your lunch break.

However, the hopeless optimist in you (you know, the one that still isn’t jaded enough to know there isn’t a purpose to all of this) still believes the sprint will actually go well. That is until you start working and realize that the user story you’re supposed to be working on actually impacts 2 thirds of the application and it might break it. And you’re supposed to finish it in a maximum of two days. After all, you DID agree on the complexity, right? Undaunted, you proceed to work and, given that you’re an optimist that still cares, you actually manage to finish the work on time and send your code into the review phase. To those of you not knowing what that is, it’s a phase where another developer takes a look at the code you have written to make sure it makes sense and to also brag to you about how much better he is than you peons beneath him.

And of course, this phase which should take about 10 minutes ends up taking 3 days. During these 3 days, you constantly reach out to the Scrum Master, Team Lead or anyone you can think of in order to figure out what to do next. There is no definite answer to this, so you’re stuck with guiltily browsing imgur or 9gag. Meanwhile, the testing team keeps pressing you to allow them to test what you have done because they’re stuck and have nothing to do. The team lead reluctantly agrees to this course of action and also tells you to start working on something else.

There is a shred of happiness though, as all this ordeal lasted so long it’s already Friday and the weekend is upon you! Two days free of all this crap. At least you can have some serene time of your own when you can once again ponder becoming a lead singer and be as good as Freddie Mercury.

As the weekend passes and Monday comes around the corner once again, you open your e-mail client and find 247531 code review suggestions which you have to implement. You start considering sneaking some good old Scotch to work to make this slightly bearable and implement the changes. You also inform your testing colleagues that they would need to retest this after you’re done to make sure nothing’s broken.

The rest of the week usually finds you hastily coding just about anything you can think of since the Scrum Master realizes that there is no way you can deliver the story points the team committed to and some stuff will end up presented in the demo without it being tested thoroughly, which annoys the testers quite a bit. Demo day is usually on a Friday, so as to have a good start to your weekend, right? Uhm…right?

Demo day is upon you…well not you in particular, unless you drew the short straw and actually have to be the presenter of the whole thing. And as the demo goes on and the user stories the team worked on work…almost well or not at all, you once again find yourself contemplating what life would be like if you became a lead singer and be as good as Freddie Mercury.

After the demo meeting, there is usually a sprint retrospective meeting where everyone says what went well, what elements of the working process should be kept and what should be improved upon. This usually gets written down somewhere by someone, only for it to be long forgotten by time for 3 ages until it is rediscovered along with some ring or whatever which is used by this Dark Lord to annihilate all tech companies that still use Agile.

After the retrospective, you breathe a sigh of relief, only to have reality softly creeping in again and realize this will start all over again after two days. You once again find yourself contemplating what life would be like if you became a lead singer and be as good as Freddie Mercury. You also have the tendency to shed a tear right before you go to bed or outright cry yourself to sleep, because this is what your life has become, after so many unicorn promises made to you while you were in college or an intern in the same company you now wish would go bankrupt so you could actually leave this dead-end job which otherwise will continue consuming you like the one ring that rules them all.


2 thoughts on “A typical sprint

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s