Estimating is hard.

I’m pretty confident that I’m a cautious person. Get it?! With that in mind, I should not have been surprised that I had over-estimated the story points in my IPM for this week. I think it was a combination of my high estimates for pessimistic (none of the natural disasters I accounted for ended up happening), and some of the admin items I had in my iteration for this week ended up taking five minutes instead of the one hour that the smallest story point of 0.25 defines.

I finished all my story points after only one day, I will admit it was a good problem to have encountered, the other way around would have been worse. That said, it has highlighted that estimating is something that I need to work on. I’ll be working on it naturally anyway since I will have an IPM every week, and the understanding I have of my own abilities will also improve as time goes on. At the moment, my minimal knowledge of Java is pushing the pessismistic estimations high.

With an empty sprint plan, I turned to my mentors for next steps. Uku is on a client site most of the week, but was very quick to respond on Slack and suggested I sit down with Mateu to determine what the next steps should be. Mateu quickly made a bit of time for me and we sat down to look at what I’d done. This was the first time I really started to see how my mentors were going to approach the apprenticeship. Mateu was in full “I’m the client” mode, something I hadn’t quite realised I would be dealing with immediately. It was a good move though, because it brought to something to my attention about communication with the client during an IPM: Ask questions!

If something is left unasked, then a judgement must be made on how that thing should be implemented. The chosen implementation has a good chance of being correct given the application of some common sense and experience, however, there is always a chance that it is wrong. If it is wrong, and it wasn’t discussed then it’ll need to be changed, if it is wrong and it was discussed, then theres another lesson in there about better communication but it’ll probably still need to be changed. Importantly though, the chances of something being correct are improved if a sensible discussion with the client is had for example:

Me: Let’s add some error handling to the user input marking.

Mateu: What do you mean by error handling?

Me: Umm.. actually it’s really input validation that I’m talking about, so players can’t make marks outside the boundaries of the board, or press other keys that might cause errors.

Mateu: Ah ok, that makes more sense.

Me: Also, when someone presses an invalid key, we should probably give them a message to say so, shall I put something together or do you have something specific that you want the message to say?

Mateu: Actually yes, I’d like it to say …

As I started to acclimatise to the concept of treating Mateu as a client, I started to understand the benefits of good communication in those moments. So asking questions like “What would you like the message to say?” lead to more specific acceptance criteria for the story and as such a higher likelihood of a happier client at the end of the sprint.

More Java TTT tomorrow, hopefully I won’t have to bother so many people with all my questions. Slowly though, my knowledge of Java is improving, and as such knowing what to search for online is becoming more obvious.