What type of Buysiness Analyst are you?

Ranging from the Business side to the Technology side, Eric Provost defines 4 types of Business Analysts.

Here's the four profiles, from Business Oriented to Technology oriented:

- The Strategic Analyst

...focuses on the organization as a whole...

- The Business Process Analyst

... works to understand current business processes in the organization in detail...

- The System Analyst

...also known as the Functional Analyst, uses the high level, business process-based requirements elicited by the Business Process Analyst as his main input...

- The Technical Analyst


...the one linking the business and system requirements to the bits & bytes of the system...

I would add that sometimes the Business Analyst must be a bit of all the four profiles above, specially if it's nearer to the Technology side.
Sometimes you have to wear the four hats, on at a time :)

Here's the link to the full post: https://www.ericthebusinessanalyst.com/quiz-types-of-business-analyst/

Have fun! :)

"The Junior Business Analyst Manifesto", by Eric Provost

Hi!

Came across this post on Eric Provost's blog.
Rather interesting, either if you're new to the job, or even if you need to be reminded of some of these things

Here's the summed up topics & some brief take-aways:

1. You shall ask questions (always)
...you have to know how users work to elicit good requirements...

2. You shall master the art of data analysis (embrace the spreadsheets)
...Data is power... Data is hard... Take time to play with data...

3. You shall challenge the status quo (change is stability)
...Ask questions (rule 1). Look for the truth in data (rule 2). Ask questions again. Never accept “because it always been like this” as an answer...

4. You shall aim for the best solution (yet keeping it simple, stupid)
...you’re tempted to suggest the crème de la crème... And you shall not... first look at how you could optimize the processes...
[KISS = Keep it simple, stupid or the nicer version, Keep it simple and smart]

5. You shall communicate (again. and again. and again.)
...Business analysis is all about communication...

6. You shall track your work (every. single. day.)
...you still have to project yourself 5, 10 years from now... Will you be able to track everything you did in the last few years?...

7. You shall widen your horizons (be a multidimensional BA)
...Don’t hesitate to do more than what is expected from you... Business Analysis is a multidimensional discipline...

Full post in here: https://www.ericthebusinessanalyst.com/junior-business-analyst-manifesto/

Have fun! :)

"Control Your Emotions & Be Positive", by Yoshito Hori

Came across a very interesting article about the relation between controling our emotions and leadership.

Some takes of the article (really interesting!):

- TAKE 1 :)

Techniques to control your emotions:

STEP ONE: Jettisoning anger

• Analyze WHY you are angry.

Thinking rationally automatically switches your brain function from the emotional to the intellectual.

• Execute an EMOTIONAL “REFRESH.”

Do something to take your mind off your anger. Play basketball, go for a swim, find some friends to chat to.

STEP TWO: Controlling the emotions

• Try to recognize the emotion you’re feeling.
• Judge if that emotion is a positive or a negative one.
• If it’s positive, amplify it. If it’s negative, reduce it.

- TAKE 2:

Carlos Ghosn, the charismatic French-Lebanese head of Nissan, is respected in Japan and worldwide for his rescue of the struggling national carmaker in the late 1990s.
Ghosn bases his approach to public speaking around a simple cast-iron rule: Your audience will forget 90% of what you say within 24 hours. What stays with them is your attitude, your emotion, the feelings you convey.


Here's more:
https://www.linkedin.com/pulse/lesson-leadership-control-your-emotions-positive-yoshito-hori

Have fun! :)

"It’s Effort, Not Complexity", by Mike Cohn, and the relation (?) between Story Point estimation and Time

Mike Cohn establiches a relationship between Story Point estimation and Time, a relation which is not consensual.

He says it better:
"Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery – snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points – each is expected to take the same amount of time."

Take a look. It's in here:
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity#.WR3nW4OtKng.linkedin

Have fun! :)

"7 Traits of High-Performing [Lean] Teams", by Maja Majewski

I came across an article about High Performing Teams.

It's in here: https://leankit.com/blog/2017/03/7-traits-high-performing-lean-teams/

Although the article is lean-oriented, I believe these 7 traits are easily applicable to any team with a high performance motivation.

So here's my interpretation of these 7 traits to any team who values High Performance:

1. They Don’t Let Lack of Lean Experience Stop Them

Your team wants to be a High Performance team. So, if you use any methodology that is Agile oriented (it helps :)), if your team is not very experienced with the used methodology shouldn't be a problem, as long as the team WANTS to performe better and better.

Motivation is key!

2. They Have an Executive Champion

It really helps a lot to have your top management with the same mindset. It allows the team to have space for trying and improving in a continuous improvement environment.

3. Their [Lean] Journeys are Unique

Any path to adoption of a high Performance mindset can lead to success, as long as the team is committed.

4. They Have a Dedicated [Lean] Team/Position

Having someone pushing forward and always reminding the team to do better, and how to improve more and ore is a key facto.

In many Agile adoption teams, it is really helpfull to have a good (!) Agile Coach.

5. They Use Power Tools

Make teams use the best tools suitable to each reality. Use them well and they will surely help!

Make the best out of performance measure tools, task oriented tools, etc.

6. They’re Laser-Focused on Flow

Increasing team productivity, make processes more and more efficient, and use the best change management tools available, will surely contribute to improve the frequency of quality delivery.

See more in here: https://leankit.com/blog/2017/03/flow-lean-executives/

7. They’re Metrics-Obsessed
"metrics allow teams to paint a holistic picture of their current and past performance, helping them make targeted improvements" - couldn't say better, really :)

Good metrics are very helpful indicators on how we're doing. So, teams should be taking the best out of metrics, in order to improve continuously.

Have fun! :)

"The tragedy of 100% code coverage", by Daniel Lebrero

"It is funny how things turn around. ​ For fifteen years I have been preaching TDD (Test-driven development, or as it used to be called: test-first approach), or at least for developers to write some unit tests. However, in recent times I have found myself saying more often, 'Why did you write that test?' instead of, 'You should write a test.'"

Daniel Lebrero on 18/05/2016

It presents some interesting opinions & views, worth to take a look...

It's in here: http://labs.ig.com/code-coverage-100-percent-tragedy

Have fun! :)

"User stories are not requirements", by Emal Bariali

Interesting article that deepens the role of the Business Analysts, and makes it go the extra mile!

The takeaways from the article:

1. Recognize that your output as a BA has huge downstream impacts.
2. Understand that meeting the needs of your downstream stakeholders (the dev team) are as important as meeting the needs of your upstream stakeholders (the business side).
3. Learn what it takes to make sure your downstream stakeholders have what they need to build a solid solution.  A little bit of "systems thinking" will take you a long way to help meet the developer needs.

I would sum it up in something like this:

1. BA work is crucial for downstream 'stakeholders' *
2. The BA works for up and downstream 'stakeholders'
3. Do some System Thinking to be sure the requirements are fully understood by downstream 'stakeholders'

* not sure I agree with this term but it works for now...

It's worth to take a look :)

Here's the full article: https://www.linkedin.com/pulse/user-stories-requirements-emal-bariali-mis-csc?trk=mp-reader-card

Have fun! :)

"The Scrum Guide" - Free eBook :)

Here's a link to the "The Scrum Guide" in the views of Jeff Sutherland and Ken Schwaber:

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

It intends to be "The Definitive Guide to Scrum: The Rules of the Game".
Personally, don't agree with it all, but, hey, nothing like having a critical reading perspective, right? ;)

Nice readings & have fun! :)