Rules for best analyst ever

As a follow up to “how to hire best analyst” here are some factors I think are important to organize your company this way.

Allow your team to be us vague with estimation as they please (don’t hold it against them).

I’m positive and maybe little bit romantic if it comes to human nature. I believe devs gives big estimations in two cases: when the feature is big or when there’s too many question marks around it. The former tends to be underestimated, the latter – it’s mixed, but it’s not uncommon to see the estimated work shrinking along the way, when the intentions are uncovered.

I’ve never experienced big estimation because dev team was lazy and wanted to take a little rest next sprint.

Anyway your team will be precise when requirements are clear.

Other trick you can use is to ask estimates with error margin. In general you will be getting X+/-10% (where X is an estimate). But the +/- part can hold an information with how much uncertainty devs are dealing with. It will be non-zero all the time because shit happens and devs know it. But when it grows to ridiculous – there’s much uncertainty there.

I use estimates with uncertainty margin only for pre-estimates: it’s not story for next sprint, but PO wants to know how much (more or less) something will take. So they can make rough plans.

Allow them not to start working when not enough resources available

And mentioned resources are most often information. This is not always possible. Our solution is clear information (with some CC to important figure in the e-mail if needed): “ok guys – we’ll start working on feature Foo despite not having all the information. But please keep in mind it is possible we’ll need to throw everything to trash later, because we’ll make guess-assumptions – we’ll be flipping coins”.

On the side note: I’m sometimes harsh when it comes to communicating such messages. But the goal is not to feel nice – my goal is that everyone understand. Like this flipping coins – I would say that as I mean it. But of course down the road we would ask PO any time it makes sense. I just want them to feel this chill on their necks for a moment.

Teach everybody that code is not gold mined from deep underground

You don’t need to store as much as you can. It’s ok to throw it our. (this is difficult part for devs)


much hard work

I actually feel the best when I can remove a lot of code.

For this you would need someone who can take lead and who live by that principle. Someone who feels secure enough – so he can comfort your team when that happens.

This is not all, probably there are some small nuances which I don’t see. If something comes to my mind – I’ll share. Please to that also in the comments.

Share Button

2 thoughts on “Rules for best analyst ever

  1. Pingback: How to hire best Analyst / Architect | webbricks

Leave a Reply

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