Monday afternoon, you are working on your ticket which was planned for about a week (I know that with T-shirt sizes there is not direct reference to hours/days - or should not be - but... when you have a pile of things to do, who does not convert the effort in the time it will take?)
Let's say the estimate has been quite loose, accomodating, the task seemed quite easy to everyone but there were some unknowns, so some buffer was added and the highest number on the poker cards was approved.
The sprint will end on Wednesday and you will be surely done tomorrow. Or not. That depends on you.
In a previous post I was telling about the bad habit of saying "I am almost done" during Stand-ups or Status Update Meeting (and the fact that most of the time, when you say that, you end up inevitably NOT meeting the deadline, for one reason or another).
So if you think you are done with your ticket, before the estimated time, what should you do?
Well... not really.
If you see that there are other tickets pending, that would not make it within the sprint ( or that could delay the delivery), it could be a good idea to grab them and work on them, wouldn´t it?
Slacking off, or stressing out trying to work faster and faster are the two extremes. What I´d like to point out here is finding the right balance. That is being proactive, working hard, but also taking your time.
What does it mean, take your time?
Should you slow down, on purpose, to not let your agile-coach/pm find out you will be soon without a ticket?
Of course not.
But if an estimate was done properly, the sprint was planned properly, and you have some time left - instead of rushing into the next ticket - you could spend more time on the same task, to test it even more thoroughly, you could read more the documentation of the library you used to achieve the task, you can think of more edge-cases for which you might need more unit tests, or you can simply reason about possible improvements (write them done somewhere and bring them up the next sprint planning), or you can summarize the challenges and the learning out of that ticket and prepare a Show&Tell or small presentation for your colleagues
Eventually, but ask your lead beforehand - you could even take those couple of hours to watch that online course about AWS you subscribed, but never completed.
Nobody is there with a whip shouting at you to be quicker. And even if there was ( and I hope is not ) now that you have some buffer, take that opportunity, don't do yourself harm.
Don´t lie, don´t cheat, but be smart.
We developers are always complaining that we do not have the time to code how we wanted, that we have to sacrifice quality to deliver on time, that management does not care about technical debt - and then when we have time left we don't take it (and make good use of it).
Take your time, use the time you have.
It's called a Sprint, but it will pay off in the long run.
Photo by Braden Collum on Unsplash
Top comments (2)
This is definitely something that takes experience to learn about yourself. You will find that you will actually be more productive by pacing yourself. I used to work through lunch and work late trying not to break my productivity streak. Nobody wants to stop when they feel they are on a coding roll. Yet I was always busting deadlines and I felt unproductive.
Taking a full lunch breaks and spending time on professional development like new technologies actually increased the amount of work I could do when I was coding.
yes. taking time to learn is fundamental. taking time to recover or enough breaks as well. (I learned it recently from sports. I always want to train and do stuff, but - especially getting older - your body needs (at least one) a rest day to fully recover and grow.
lunch in front a computer is never good.
and if you are stressing out for a bug you can't solve... most of the time is better to take a break and go play kicker or tennistable - come back with a fresh mind and nail it!