We LOVE travelling down the rabbit holes of problems, getting hung up in the details of projects, or spending ages getting functionality working only to find out that it wasn't what the customer wanted.

If you're in the position of having to self-manage your software projects - you could find that your projects are running over, you're mis-implementing what you thought the customer wanted, or that you're drowning in bugs.

If I'm completely wrong and you're the perfect developer - this is the end of the series for you - well done!

Introduction

If you're still here then congratulations! You've passed the development ego test.

In this series I'm going to try and cover everything from managing your time, to estimating, to delivery and client communications.

But First, a Digression...

These skills take time to learn. Most of them are traits that usually get aquainted with Senior Developers, but that is down to a passive learning of those skills over an extended period of time. It does not mean that you cannot learn these skills as a junior or intermediate level developer - and certainly doesn't mean that you will know them if you happen to be a 'Senior Developer'.

In larger commercial settings, you will generally have a Project Manager whose job it is to make sure that you not having these skills doesn't detriment any projects - but in smaller settings you may find that you're left to self-manage your projects. That is where these skills really come into play - regardless of your seniority as a developer.

Interested in more differences between smaller and larger software agencies? Read my post about it here

Now back to our regularly scheduled programming:

Giving an estimate on a task != the time it takes to write the code

Hear me out - it's not entirely crazy talk.

I believe this is the single biggest killer of project timelines.

Comparing developers that I've worked with, based on how they estimate and the relative results - the difference between them is simply giving themselves enough time in the first place - allowing for the process of development from code to delivery.

This is down to being either shortsighted during the estimation phase, having a development ego that results in you underestimating what is required for the task, or (more commonly) getting too giddy about getting started on your new project so that you rush through estimations. It's vitally important that you take enough time to create quality estimates.

When estimating, you need to account for everything in your projects lifecycle. Lets take an example:

As a user I want to be able to register for the site

An average breakdown of the story from a developer;

Development of registration form (1 hour)

Development of registration endpoint (1 hour)

Very simple. Now lets look at what this story is more likely to include;

Development of registration form (1 hour)

Development of registration endpoint (1 hour)

Testing of feature (10 minutes)

Pull request review time & any changes that need to be made (20 minutes)

Push to staging environment (Free - if you've set the environment up already, and don't have to manually deploy)

Arrange QA & resolve any bugs that arise (10 minutes)

Pull request to live environment (5 minutes)

Push to live environment (Free - if you've set the environment up already, and don't have to manually deploy)

Test on live (10 minutes)

Notify/Demo with the Customer (5 minutes)

Already we're 50% over our estimate, had we not thought about just some of the things that could increase the time spent on a feature. This is assuming that you wireframed the functionality out - AND spent enough time on your user story and acceptance criteria writing - so that the development was all but bang on.

Which leads me on to the next point.

Write good user stories

Dependant on your situation, you may or may not write your specification/user stories. It's incredibly important if you're on a large project that you capture enough detail in your stories. It's no good estimating well if you're only estimating half of a story, or if that story is missing out half of the detail that has been given to the client.

When writing/evaluating/estimating user stories - think about the following things:

Is the user story trying to cover too much?

Generally, if your estimate on a user story is over 4 hours - it's trying to accomplish too much. You're going to miss out on detail and it's going to be hard to be accurate in your estimates.

Does the user story have enough detail in it?

A user story should define a user group, a goal, and a reasoning for that goal at the bare minimum. This ensures that developers know exactly who and why they are making the feature - which will naturally lead to more appropriate UX choices.

Other areas for detail include Acceptance criteria, which will let you know what needs to happen to satisfy that story; Do I need to recieve a success message? Should it tell me that my email address isn't unique if it isn't successful for that reason?

Are there other assumptions that help build this story into the project?

A story on its own is a single piece of functionality. If your specification isn't the most detailed - you'll end up with a clunky product. Are there user stories that cover the verification email for the registration, or was that included in this story? It's vitally important that whilst you estimate well on a story-by-story basis, the overall scope gels.

Ensuring the the user stories are good whether you've written them or not ensures that any developers that estimate/work with them (including you) will have a more seamless ride through your project, with as little surprises as possible.

Do not blindly give an estimate unless you know enough about a story

This sounds stupid, but I see it every. single. day. Ask yourself;

Am I confident that I know enough about the story to estimate on it?

If there are large unknowns left on a story - then do not estimate on it - go and scope it out for some more time. You may aswell kick the chair out from under yourself if you estimate on these.

Of course, I'm not saying that you can't estimate when it's a situation such as;

Final imagery hasn't been provided

The copy for the content on the email hasn't been sent by the client yet

I'm saying that if it's anything like the following;

It's an integration and you haven't looked at the API documentation yet

There are any functional TBC's

You're unsure of the purpose of the story and why it's been created

Please do not make a blind estimation. It will come back to haunt you.

Conclusion

We've scratched the surface of estimations. Through trial and error you'll pick up the knack of just knowing when you need to dig deeper into a story and when you're okay to estimate on it.

We have a load of topics left to cover such as:

Quality Assurance

Client Communications

Managing Expectations

Release Schedules

Organising sprints

Prioritisation

So if you found this useful join our mailing list below to be notified for when the next part is out.

See you soon.

Liked what you saw?

Feel free to leave a clap(s) as a gesture of thanks. You can choose to clap once, or leave a
round
of applause dependant on how you found the article.

Join the mailing list

Want to be alerted when new content comes out? Join my mailing list to receive
notifications.

Join the Mailing List

×

I'm glad to hear that you want to join my mailing list.
Please enter your email address below and it won't be long before you start recieving content.