Skip to main content

N things I want from a Business Analyst....

  
Business Analysts. I give them a hard time. I really do. I love them really but I couldn't eat a whole one.

Is something I used to say.

I even went to a Business Analyst meetup once and asked them if they thought they should still exist in our "agile" world or are they being washed away by the tidal wave. Looks can really hurt, in fact they can be pretty pointy.

I wouldn't do that now though, I think I've grown up a bit. Like any great programmer or tester they can really add to a team. And, conversely, like a really poor programmer or tester they can really do some damage. It was unfair to single them out and very possibly bandwagon jumping of the worst kind.

In addition, I fell into a common trap. I was full of hot air when it came to what was bad about Business Analysts, but could not articulate what might make them great.

So here goes............
  • I want a vivid (preferably visual) description of the problem or benefit - lets face it, none of us are George Orwell. We can't describe in words with clarity and paucity, all the complex concepts present in our lives. However, we can deploy many techniques bring flat material to life. Elevator pitches, mind map, product boxes, models, personas and the like are your buddies.
  • I want you to shape a backlog, not provide a shopping list - hearing a backlog described as a shopping list leads me down a path of despair. A backlog is themed beastie, which needs to be shaped. Delivering the stories in a backlog will not implicitly solve the problem, no more than a lump of marble and a hammer/chisel constitutes a statue. Items in a backlog are raw materials. They need sculpting with care to achieve their goals.
  • I want you to work in thirds - for you lucky so and so's who are trying to figure out how on earth to cope in the agile tsunami which is enveloping the world, here's a rule of thumb for you. One third, current sprint, one third, next sprint, one third, the future. The remaining 1% is up to you.
  • I want you to be technically aware but not necessarily technically proficient - technical awareness is a beautiful thing, many testers are a good way down this path. Knowing the strengths and weaknesses of given technology helps you to realise business benefits, because you can appreciate the whole picture, the need, the constraints, the potential.
  • I want you to really, really try with para-functional requirements - This is in two parts, the response times/capacity/scalability the business needs for the real world, coupled with the constraints of the technology deployed. The answer will be somewhere in the middle. If there is anything I have learnt about performance testing especially, is there are few absolutes, para-functional requirements should reflect that subtlety.
  • I want you to be experts in change - in fact you guys should love change deeply, being able to extol its benefits and risks. Helping teams to help their stakeholders realise the value of change in their marketplace. Not snuffing it out to protect business goals which time has rendered of dubious value. 
  • I want you to distinguish between needed and desired - this burns me deeply. The old chestnut about a small percentage of the product actually being used (linky) is serious business. By not determining the difference between what is needed and what is desired, products are being happily helped to fall silently on swords forged by Business Analysts who struggle to articulate this critical difference.
  • I want you to recognise that stories/use cases/whatever are inventory - Imagine the backlogs as a factory, piles of stuff everywhere that our brains are trying to navigate around, winding a path through these piles of stuff trying to find what we need. This takes time and steals from flow, which we can't afford to lose. Before you add it, stop and consider for a moment, whether or not you need it right now.
  • I want you to challenge really technical people to justify value - "Well, we'll need a satellite server configured with Puppet to centralise our upgrade process." Huh? We will? What value does that give the business? Is what I want you to ask. Anything worth building, should be worth articulating as a value proposition.
  • I want you to take ownership of the product goddammit - There ARE decisions you can and should make. If you wish to survive the agile tsunami its time to embrace that change is king, and it means decisions. Big and small, narrow and wide, they are there to be made. By you. YOU.
  • I want you to continuously improve and I'll be watching - I would never want you to do 10 things to improve yourselves. 'N' things please, ever changing in focus to ensure you are delivering value in the contexts you find yourselves.

Basically I want you guys to be superhuman. I think you can be.

Some say being a Business Analyst is old hat. I say it is a gift. But only if you embrace it.

Comments

  1. Really you mention very important abilities for business analysis ts.I quoye your mentions in my business analyst training in teaching.we look for more from you.thank you.

    ReplyDelete

Post a Comment

Popular posts from this blog

Testers Guide to Myths of Unit Testing

One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.

Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:
Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? #development#agilepic.twitter.com/4oT5HE4qs3 — Ash Winter (@northern_tester) December 19, 201730 replies with ideas tends to indicate that people might be into it. 
The ListI thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:
That developer…

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…

Why do Testers become Scrum Masters?

It was late and I was stuck on a train, so I pondered on the question of why do testers often (in my experience) become Scrum Masters. Its a very dear question to me, as its been a big part of my career journey In fact, I've been there and back again. Tester to supposed-to-be-testing-but-being-a-Scrum-Master to Scrum Master, back to Tester and very happy thank you.

I encapsulated my reasoning in the following:
Long train delay, decided to think about a thing. :) Why do testers (in my world anyway) often become Scrum Masters? #testing#agile#scrumpic.twitter.com/FGGXFiBGz1 — Ash Winter (@northern_tester) February 13, 2018The tweet got a lot of traction, and generated a couple of interesting threads which made me think.
Great list. Personally I think that as a scrum master I can add even more towards the goal of quality. — Christian Kram (@chr_kram) February 13, 2018 Perhaps part of the reason for the transition is a growing appreciation of where quality has its roots? If testing i…