Movebubble Sprint: Day 1

It’s Monday morning and we’re starting a new sprint today. These days are generally pretty hectic – a lot of meetings (sprint planning, weekly KPIs, cross-team catch up, dev catch up) and a lot to think about (what can we commit to in this release? what’s still outstanding from the last one?). Today doesn’t get off to a great start because we arrive into the office to discover that neither of our internet providers are working – apparently some external issue with a cable. So after the standup I bring forward some of the other meetings that I had planned for the day with the hope that the internet connection is back by the time they are done.

I attend two standups – one at 9.45am for my team (Water Camels – don’t ask) and one 9.30am for the other development team (Space Monkeys). The idea is that myself and Adrian, the two lead engineers, attend each other’s standups to ensure we have a good picture of what both teams are doing to try and guard against lapses in communication when the teams are working on cross-functional spaces. Once standup is over, we ritually head down to Hopper to grab our coffees, which is a chance for a slightly more informal catch up (‘hey, how was your evening’ type thing) with the other members of the team.

At 10 we have our dev catch up, brought forward since we’re without internet. There are three developers in Water Camels and we sit round like this every week for 20-30 minutes as a chance for everybody to raise any concerns they have with development, planning, process or anything else really. A couple of really good suggestions have come out of these in the past few weeks; this morning we don’t have much to talk about until Laura suggests we discuss how we’re going to handle Jordi’s remote working arrangements when he starts working from Barcelona. It quickly becomes apparent that our expectations on this are misaligned and this is something that we’re likely to have to work on in the coming weeks.

The internet is still broken when I get out so I then have a catch up with the CTO. We don’t have too much to say; I have a couple of suggestions about how we can reduce the support load by making a key component testable at an earlier phase in our development cycle, however while I do get his buy in I feel like getting the time to actually implement them is unlikely in the next month or so. As a startup with a limited roadmap we’re under constant pressure from business requirements to be implementing new features at the expense of investing in infrastructure and other NFRs; this is something I will need to push for but I don’t see it getting done before the start of May.

Then there’s one last catch up with Jordi regarding his working arrangements before we’re into sprint planning. This is a new relatively responsibility for me, one that I’ve been doing for about 6-8 weeks now. Previously our Head of Product (Will) was handling it but his workload was even more demanding than mine so we decided to split the burden of managing the planning overhead for our team.

Currently, our process is to do a technical planning session on the Thursday before a sprint to pull out all the individual technical requirements and write those up as stories. I’ll then spend a bit of time the following day updating the descriptions and requirements and following up individually with the designer and developers on any outstanding questions, then Monday is really just about sizing the work and then negotiating with Product as to what we can commit to for the next sprint and/or release.

Today, it takes me about 15 minutes to prepare for the meeting than at 11.30am I sit down with Sunil (our team’s designer), Jordi and Laura and we estimate all of the tickets with story points. We allocate points in sizes of 1,2,3,5,8 or 13, where 1 is ‘I could turn this round before you finish your coffe’, and 13 is ‘er, fuck, that’s at least 3 days, maybe we should break this down a bit more’. We try to keep our stories as small as possible as it helps ensure that they are testable and tested. Most of them end up being in the 2 to 5 range (a couple of hours to around a day a half).

We’re targing 30 minutes for planning but we overrun slightly and it takes 45. I then sit down by myself to close off the previous sprint, chatting to each of the others individually at their desks if there is anything in an ambiguous state and moving across an estimate of the relevant number of story points for any unfinished items. It looks like our velocity for the last sprint was about 35 points per week – I’d like to get this up to 45 or 50 but in order to do that we need to reduce the support load. Also, 11 of those points represent scope creep, but I don’t think this is so much of a problem – the nature of our business means there are always things which are ambiguous or missed when we start a development cycle, we just need to make sure we account for this in our planning.

As a result, I reckon that we can handle around 60 points of work before our next targeted release on the 7th April. We’ve estimated the new feature at 73 and have around 10 left over from the previous week (as a direct result of scope creep). I communicate this to Will and we sit down and go through the design and identify around 20 points of work that aren’t required for a true MVP. This takes around 15 minutes; what results is an aggressive but achievable sprint commitment for a paired down version of the new suggested properties feature. I make the appropriate adjustments to our sprint board and then grab a quick 15 minute lunch.

It’s 13:30 and I haven’t written a single line of code.

The afternoon is more development-focussed – and more chaotic. I released some code on Saturday (I don’t normally work weekends, but the code in question was for an overnight job and I really wanted the results to be ready on Monday) and as a result there are a couple of support items that need my attention. One is a configuration bug with the code I released which is easily fixed, but which has highlighted a missing case in our business logic – some events are being fired which make an assumption which isn’t true and so I spent around 90 minutes fixing the code to handle that missing assumption.

During that 90 minutes I also fire off a communication about the scope of our new build, help to diagnose another issue surfacing with our chat feature in live and discuss the outstanding work that needs to be done for our new split testing framework (which is related to the Saturday release). On the back of diagnosing the chat issue, I then need to apply a fix to ensure that we are migrating some dates correctly, as this is affecting our SQL replication (we use a document DB for our production logic and replicate this to a SQL database for use by our data scientist). This takes me about 50 minutes.

Before I can do that though we have a cross-team catch up – once a week, we have a group ‘standup’ where we tell everybody what our main goals for the week are, another attempt to ensure we keep communicating cross-team. I also need to check up on the SQL replication for the split testing code so we can analyse a dry run AA test and check that users are being assigned to cohorts in the correct proportions. There’s a test for a viewing reminder that needs fixing and another chat-related test that has started failing due to Daylight Saving Time. And just when I feel I’m getting on top of it, Jordi identifies a problem with the React Native router that we’re using in the agent app, which basically makes it impossible for us to achieve the navigation structure we’re aiming; at least, without further diagnosing the issue in the third party library.

My day finishes at around 18:15 – I have a 5-a-side game at 19:00. It’s been a particularly chaotic one; so much context-switching has left me with the distinct feeling that I’ve forgotten to do something important, not dissimilar to arriving at the airport and suddenly panicking that you’ve forgotten your passport, or getting halfway to work and glancing down quickly to check that you remembered to put your trousers on. Most days aren’t quite this crazy but then the constant feeling of having a million things to do is energising in a peculiar way.



Leave a Reply

Your email address will not be published. Required fields are marked *