Skip to main content

Tag: Agile

What your burndown charts are telling you

When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed

from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points cleared which in my eyes, drives some adverse behaviours.

In this blog, I’d like to show some example burndown charts I’ve come across in teams I’ve been part of as a Business Analyst and what they should be telling you about how the team is operating. I’ll also offer some suggestions to fix what could be barriers to becoming that high performing agile team we strive to be.

So what is the purpose of a burndown chart?

A couple of quotes:

‘Burn down charts are a run chart of outstanding work. It is useful for predicting when all of the work will be completed’- Wikipedia, 2019 <“>https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown>

We can take it from both of these quotes that the purpose of the burndown chart is to be able to visually see progress through a sprint, however I’d like to emphasise Mike’s point in his description that it ‘is a way to clearly see what is happening…during each sprint’. On many of the teams I’ve worked on, if not most, burndown charts are not reviewed at all but only looked at if someone outside the team wants to see them.

I’m well aware every burndown chart will have its own unique story behind it so when I give what I think are reasons behind the chart in the examples below, I’m only hypothesising from my own experiences. And while the burndown doesn’t tell the whole story, in my experience the analysing of them (with the whole team of course) has always improved the ways of working and that is the purpose of this blog.

Note: in the examples below, each sprint is 2 weeks long with the grey line depicting expected burndown with the red line the actual.

Example 1

The ‘Manhattan skyline’ burndown

BATimes APR2 1 2020

Possible reasons

Ok, it’s not exactly like wonderful Manhattan but you get the idea (up and down peaks across the sprint). I think the two key parts of this burndown are the long flatlines at the beginning and midway through the sprint and the spike 3 days in. While this doesn’t affect the sprint points (what points/stories have been added have then been removed), it suggests the team weren’t confident of completing what was going in to the sprint for a significant increase (30 points). Or possibly, the stories weren’t ‘ready’ for the sprint. Also, have the team bitten off more than they can chew during sprint planning as there are 10-20 points left on the table at the end of the sprint?

How to fix

During sprint planning, ensure all the stories that are sprint candidates have met the team’s ‘Definition of ready’ and the team are confident that those stories that are being taken can be completed within the sprint. This may take some time for the team to get to this point as estimation and sprint planning (for me) are the two areas of Scrum that take most time before the team are comfortable with both aspects. And in my experience, if the team get these elements right (well estimated stories and confident planning), sprints tend to go pretty much as planned.


Advertisement

Example 2

The burn down-up-down-up chart

BATimes APR2 2 2020

Possible reasons

I think it’s fair to assume this team is clearly having problems as you can plainly see but what might be the potential cause of this erratic burndown (or burn across!!)? Firstly, it’s clear the team have taken on way too many points for the sprint. Of course, there could have been an issue near the end of the sprint that caused the team to stop developing but even so, to fall short by 30+ points should be saying something. Long flatline periods suggests stories weren’t small enough to deliver incrementally. Large increases in points mid-sprint suggests the team have not been disciplined enough in saying ‘no’ to new stories being added. If these stories had not been added (20+ points), then the team may have achieved its target.

How to fix

Don’t be fixated by how many points can be done in a sprint. Just because the team did 60 points in the previous sprint, don’t assume the team can do it again the following sprint. I’m a big fan of Mike Cohn’s ‘Capacity-driven planning’ and I feel it’s the team’s responsibility to confidently be able to say, ‘yes, we can commit to everything in this sprint’. In velocity-driven sprint planning, I tend to see the thought process of what was achieved last sprint and therefore what stories can we cram in to achieve the same number of points or more. I think this approach is counter-productive and brings wariness to the team’s ability to confidently commit to the sprint. Therefore, ask the question, ‘what can we confidently achieve in this sprint?’ as opposed to ‘how many points should we do in this sprint?’

Example 3

The Flatliner

BATimes APR2 3 2020 

Possible reasons

My first thoughts on seeing this burndown was, ’should you even be using agile as a framework for delivering your project?’. I think you’ll agree that from day 1 of the sprint, 35 points have been added before work’s even started. Then there are no points (or virtually no points) cleared for 8 days before a big drop of 20 points and with still 40+ points left on the table. It could be this team is very early in its agile journey and therefore are unclear on their velocity (hence so many points) but still, loading up a sprint with no idea as to velocity suggests immaturity of an Agile delivery framework.

How to fix

In my view, the type of work being carried out by the team might suggest they’re unable to deliver iteratively and therefore may be better suited to a Kanban than a sprint approach. It could be they require the use of an Agile coach or Scrum Master for a period of time to set them on the right track and start from a position where they can clear what stories they take in to sprint and build up their velocity.

Conclusion

I hope those reading this are familiar with these types of burndown charts or if you’re new to Agile and you’re utilising burndowns, my point here is to make sure you use them to analyse how the team is performing and how that performance can be improved. Of course, your retrospectives are the perfect forum to do this.

I should make a couple of points though. Firstly, don’t look at a burndown chart in isolation. I’d look at the last 3-5 to see if there are patterns emerging before you embark on working to improve. Do they look the same or do they look completely different over a period of sprints?

Secondly, don’t place too much emphasis on them. You might think that’s odd as that’s what this blog is about however, as I mentioned, each sprint is unique and each burndown will have some sort of story behind it so use them as a discussion point for the team to improve, and not the be-all and end-all to improve the team’s performance.

As a Business Analyst, I nearly always find the reason why teams don’t deliver in small increments during a sprint, and therefore creating the burndown chart examples in this blog, is down to the user stories. No that user stories are the be all and end all but invariably I find it comes down to the stories either not following the INVEST model or them not being ‘ready’ for the sprint. If you get this part right then your sprints should run smoother and your burndown chart will reflect that.

So don’t ignore your burndowns (or burnups if that’s your preferred method), and if the team’s struggling to complete its sprints, spend some time analysing them to see where the team can improve.

Match Maker, Match Maker

As BAs, we play many roles in the Software Development Life Cycle.

Sometimes we are matchmakers in working to connect the business with the solution that we hope will turn into a long-term relationship. Depending on the project, we may also play officiants (think Justice of the Peace), therapists, obstetricians, pediatricians, geriatricians toward the end of the product’s life, and even funeral directors at the end. We play a role from before a solution is a twinkle in anyone’s eye to the point where we have to lay it to rest. I may have taken a blender to my metaphors from this point forward, so bear with me.

Our first job is to put the business and the solution together. Sometimes we help the business fill out a questionnaire about likes and dislikes, and then try to find a good match. Other times we are writing the equivalent of a Tinder profile, trying to get the user to swipe right. We might even try using agile techniques, which Is the requirements gathering equivalent of speed dating, and we keep sending the business likely candidates for a long term relationship them until they find something they like.

Once we get the two to decide they want to try going steady, we spend most of our time shepherding the relationship along. It’s critical to manage expectations so that the solution never gets the “It’s not you, it’s me.” speech from the business. If it ever gets to this point, they have already cast their eyes elsewhere because the solution isn’t meeting their needs, much like real life.

Once the business makes the commitment is to go a certain direction, we generally work with the Project Manager to finalize the whole relationship:

“I now pronounce you user and solution.”

This is where the trouble can start. As compromises are made, and needs change, it becomes critical to make sure that things don’t change so much that the business or user decides they want to get a divorce. As the saying goes, “Love is grand; divorce can be 10 or 20 grand”


Advertisement

Sometimes in this process, we end up playing therapists. “How did it make you feel when the Project Manager told you the feature you thought was a must have would have to wait until the next release?” Lots of negotiation and discussion, but hopefully no tears.

Other times, we get through all that and we’re ready to start the whole gestation period, preparing the business for the arrival of the solution they’ve been waiting to see for months and sometimes even years. If we’re smart, we’ve done lots of reviews, which are the SDLC equivalent of ultrasounds, so they know what to expect. If we’re not smart, we wait until the very end, only to find out they got a boy when they really, really, really wanted a girl. It’s usually not that drastic, though.

If we’re lucky, and we’ve done our jobs correctly, we deliver the solution to the business and everybody is happy and excited for a while. Then the business starts getting nervous, being new parents.

“No, it’s supposed to do that, remember, that’s what you said you wanted?”

Other times, we just burp the baby and move on, fixing data or making a configuration change to keep things moving. Then when the parents still complain, we have to play Super Nanny, because the parents need to understand that their own behavior is contributing to the problem. When that happens, we may have to explain that there needs to be consistency for things to work right.

As time goes on, the solution matures, and we sometimes have to help fix a broken bone or two or even do a face lift. These are the ongoing bug fixes and cosmetic changes that happen over the life of the system. Usually by the time it gets to this point, there is an emotional attachment, so we have to do everything we can to keep the solution alive.

But eventually things reach the point that we become geriatricians, dealing with gradually slowing performance, and technology that just isn’t able to keep up with the demands the business places on it. We will work with the surgeons (developers) to try to keep things going, but eventually, it’s clear that we’ve reached the point where we need to lay the solution to rest.

In those cases, we spend our time planning the funeral, and sometimes we end up having to play grief counselor, as the business comes to term with the fact that their beloved solution is no more. We have to figure out how to give everyone closure before we sign the death certificate.

Then the whole thing starts all over again. That’s why they call it a cycle.

20 Lessons learnt over 20 years of doing Business Analysis

“Time has a wonderful way to show us what really matters.” – Margaret Peters 

It is quite hard for me to realise (and quite frankly a little unsettling) that I’ve been working in the Business Analysis world for twenty years now. On the one hand, I’m starting to feel old (although, apparently, life begins at forty), on the other hand there is great solace in having the benefit of having a big enough chunk of experience behind you to raise the confidence levels in most any situations that you are inevitably confronted with.

Since I like to occasionally take a moment to reflect on happenings in my life and work, I’ve decided to pen down the key lessons that I can think of that I’ve been privileged enough to learn over the past two decades.  

Disclaimer: These lessons are by no means whatsoever the ‘golden template’, ‘silver bullet’ or ultimate ‘quick-fix’ list of things to guarantee a bump-free ride as a Business Analyst. They are simply my own personal, humble observations and learnings and hopefully they can add value or help someone out there… and of course, I am still learning every, single day…

What would be exceptionally great, is if some of you would respond at the end of this post and add some of your own, most valuable lessons learnt. Would simply love to hear yours! So, in no particular order, here goes… 

1- Listen

Many moons ago, my grade 3 teacher, Mrs Momberg, taught our class the following poem (attributed to Edward Hersey Richards):

“A wise old owl once lived in an oak. The more he saw, the less he spoke. The less he spoke, the more he heard. Why can’t we all be like that wise old bird?”

My thanks go out to Mrs Momberg, for in sharing with us that little poem, I’ve learnt how powerful it can be to take serious notice of the one-to-two ratio relationship of mouth-to-ears.

Listening, truly listening, makes all the difference to correctly identifying, accurately understanding and adequately addressing the needs of customers, stakeholders, team members or anyone else for that matter whom we engage with as part of our work.

Often, I still have to prevent myself from interrupting speakers and I try to listen for understanding and to not constantly generate responses while the speaker is talking. It has been said that the highest form of respect is to listen, so I try to remind myself that by listening, I also show respect.

2- Relationships are key

Life is about relationships, isn’t it? Also, when it comes to our work. A big component of good, solid relationships revolves around trust. Building trust needs to be a focus and this usually takes time. Steven Covey famously said that “when it comes to people, slow is fast and fast is slow”. But it certainly is worth the investment of time and effort.  

A few key relationship focus points for me are:

Keeping promises. We also need to always strive to deliver on what we commit to do, since this builds trust and integrity.

Managing expectations. This extends from the base of trust that we establish. This is truly hard and certainly requires constant, daily, diligent work. But if you place yourself in the shoes of those that you seek to serve, wouldn’t you like to have a heads-up, an early warning, a convenient status update?

Be a mensch. Be a human being who is able to relate and truly see the people around you. Try to connect with those around you in a way that is not merely transactional, but even transformational. Time does of course not always allow for this, but if you work with people over an extended period, try to not always be about JUST the deliverables.

It is truly hard to properly quantify the immense value of good, trusted relationships within an organisation. The time it saves in effective communication and quick decision making not to mention not having to navigate through all the politics of who’s aligned with (or against) who, is incalculable. Solid, professional, trusted relationships just make life so much simpler to get things done quickly and efficiently. 

3- Start with WHY – build the right thing

In his book, “Start with Why”, Simon Sinek speaks about the golden circle of always starting with why. He emphasises the importance of clearly identifying the reason for doing things, for building or improving what you are doing. At the core if the concentric circles, is the question of why? 

Why are we doing this in this way? Why does it need to change?  Why are we not changing it?  

By asking Why, it forces the discussion around purpose and strategy, which is probably the best place to start. Root cause analysis supports this notion by Simon, by asking “why?” a number of times until you truly understand the root cause of a problem.

“Why” speaks to purpose, strategy and direction.

Strategy should precede structure.

The compass before the clock.

Effectiveness before efficiency.

By asking why, we attempt to ensure that we are building the right thing, BEFORE we even start to build the thing right.

Furthermore, asking “why?”, is also supported in the prevalence of the “Outside-in” customer-driven design movement. Why would customers take money out of their wallets to buy your product or service? Although there appears to be a recent awakening to the customer experience driven design, truly successful companies have inherently always paid very close attention to what their customers ask for. 

As Business Analysts, we need to constantly challenge the businesses we operate in, to ask what the true, real, underlying customer need is. Often business stakeholders assume that they know exactly what the customer needs are, but this might be tainted by their own subjective lenses through which they struggle to operationally fight the fires that rage due to their current system, process, technological or organisational culture constraints. This is where we need to step in and try to bring an unbiased perspective, possibly with the help of some customer-driven data or research to support a different point of view.

4- Ask better questions

When we ask better questions, we usually get better answers. Similarly asking the wrong questions, could lead to getting wrong answers. My learning has been to commit to spending time prior to every interaction, meeting, workshop in preparing questions that are intentional, purpose-filled and that truly get to the essence of what I am trying to achieve.

Sometimes I also consider asking a second question, upon receiving an initial response. This sometimes prompts the responder to qualify or go deeper in terms of their initial answer. 

Rephrasing what I hear as responses to my questions, has helped me to make sure that I properly understand what the responder meant. If not, they have the opportunity to correct my misinterpretation and it also shows them that I care about understanding them correctly.

To be truly impartial, especially when eliciting requirements, another key question-related learning, has been to not ask leading questions. If I do this, I plant seeds into the mind of the listener. The responses are then tainted or influenced by what I mentioned in my leading question and this is therefore not a truly, unbiased response.

5- Accept that you don’t need to have all the answers 

For some strange reason, business analysts often feel as if they need to know everything. This places them under pressure, especially since 

  1. they don’t, 
  2. most often they are in the midst of still uncovering the actual state of play and 
  3. even if they did know more than the stakeholders they engage with, this does not mean that have the answers.

The fact is as a Business Analyst, you don’t know everything. And this is okay. In fact, it is wonderful. It provides you with the unique, unbiased opportunity and perspective to see problems with fresh eyes. It gives you license to ask ‘seemingly stupid’ questions that most people are too scared to ask for fear of appearing ignorant or uninformed. Quite often these types of questions open up amazing problem-solving conversations that would have otherwise remained dormant.

Once I realised that the true value I can add is that of simplifying, synthesising and reducing complicated sets of problems, processes, information sets, etc. into structured, easy-to understand, consumable artefacts, models and documents, it was truly liberating. 

As a BA, you are expertly guiding the subject matter experts and domain specialists in a way where they volunteer information that inevitable bridges the gap between problems and solutions to those problems. This in itself, is more of an art than a science.

6- Talk to your customers

It is so very, very tempting to get so excited by and wrapped up in our own views of the problems and solutions at hand, that we can very easily completely forget about our true boss, the customer. 

Why not rather start with the customer? 

Before we embark. 

During the process. 

Often. 

During testing. 

After implementation. 

Continuously. 

The moment we get disengaged from the source of the actual consumer of what we produce, we are entering a very slippery slope. Putting myself in the proverbial ‘shoes’ of the customer, has often led to me rethinking my original ideas and approaches.  

7- No man (or woman, or BA…) is an island

Although BA’s, especially consulting BA’s are sometimes ‘parachuted’ into client sites, it is very easy to feel quite isolated and to then wrongfully assume that we have to be one-man/woman armies. This is of course not sustainable (or wise) and I’ve learnt that it is imperative to build a support structure around you to be successful and effective.

Think of identifying and cultivating relationships with key mentors, industry- and domain specialists and more experienced BA’s from whom you can learn and with whom you can consult regarding your current challenges. Sometimes just running an approach by a trusted friend, will yield some great ideas and perspectives that you cannot see from your ‘in-the-woods’ perspective.

Looking back over my career thus far, I can only truly count my numerous blessings and thank those people who gave me an opportunity, a position, a job, advice, support, or a word of encouragement along my journey. I really appreciate it and I still do!

8- Join the IIBA

If you are somebody that takes the role of a Business Analyst seriously and you regard it as a profession (and not just a job), you should truly invest in yourself to become the best BA that you can be. This means getting involved (i.e. joining) the best possible professional body in the field of your profession – in this instance (for Business Analysis), in my humble opinion, it is the International Institute of Business Analysis (IIBA). 

Since being founded in 2003, they have been widely regarded as the pre-eminent body for the professionalisation for the Business Analysis profession. As at 2014, they’ve had more than 27000 members across 6 of the 7 continents. They provide the opportunity to collaborate, network, and grow with other BA professionals locally and globally. Go join them today!

9- Get certified

Doctors, Engineers, Chartered Accountants, Actuarial scientists, etc. all belong to professional bodies and they typically all must get certified before they are allowed to claim their respective, coveted certification statuses. Most of these certifications also require a number of Professional Development Units (PDU’s) per cycle, which are essentially designed to keep certified members learning, growing and contributing to their professions. 

I think this is a very good thing. It creates an environment where certain minimum standards are created. It ensures a level of confidence for the consumers of their services, that they are getting experienced, qualified and knowledgeable BA’s in their respective domain areas. From a career growth perspective, it also serves as a decent framework of objectives against which a professional can measure themselves. 

The IIBA have created a number of certifications, which assist professional Business Analysts to build their knowledge, as they gain more experience. These include ECBA, CCBA, CBAP, CBDA and AAC.  For more on these, go to https://www.iiba.org/certification/iiba-certifications/

By way of an example, the premier BA certification currently offered by the IIBA, the Certified Business Analyst Professional (CBAP), includes as minimum eligibility criteria the following: 

the completion of a minimum of 7500 hours of Business Analysis Work experience in the last 10 years,

within this experience, a minimum of 900 hours completed in 4 of the 6 BABOK® Guide Knowledge Areas, for a total of at least 3600 of the required 7500 total.

  • completing a minimum of 35 hours of Professional Development in the last 4 years.
  • providing two references,
  • agreeing to the Code of Conduct,
  • agreeing to the Terms and Conditions,
  • passing the exam.

There are currently more than 8000 CBAPs in the world.


Advertisement

10- Apply techniques

In the late eighties, my favourite tv programme was without a doubt, MacGyver. I loved seeing the ingenious ways that he was able to come-up with solutions to get out of the trickiest situations and all of that with just a utility knife and some duct tape! Just imagine what he would have been able to do if he had more tools at his disposal…

Let us not limit ourselves in terms of our thinking when it comes to using Business Analysis techniques. Abraham Maslow famously said that “If you only have a hammer, you tend to see every problem as a nail”. Often that limited philosophy is followed in our work places and often this leads to less than optimal results.

In the Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 3, there is a list of 50 different techniques at your disposal. Yes FIFTY!!! 

There are very few (if any) Business Analysis related problems that you will not be able to solve using these techniques. Be sure to familiarise yourself with these techniques, how they work, when to use them and how to adapt them to your unique circumstances.

11- Use Modelling languages

I’ve been very privileged as a greenie Business Analyst to be taught early-on how to do modelling. I was introduced to a specific modelling language, called the Unified Modelling Language (UML). As the years progressed I have found the ability to create models, with different perspectives and levels of abstraction to be invaluable in my ability to understand, elicit, document and explain problems and solutions to my stakeholders in a way that is comprehensive and that covers all possible angles.

Personally, I believe that Business Analysts who only use spreadsheets or word processors, are missing a trick, especially since there is no way that they can accurately document or pick-up all the possible traceability relationships that one notices if you are using a good modelling language, together with a proper modelling tool.

There are very few things that irks me more than people who calls themselves professional Business Analysts, who walk out of an elicitation session with a bullet-point list and then call that a specification. Understanding proper perspectives when modelling, ensures that the BA answers all the various Zachman dimensions, like who, what, why, where, when, how. 

Modelling languages provide tried and tested diagram types that can assist the BA in defining scope, identifying system integration information, depict process flows, identify state transitions, document relationships between sets of information, identify rules, constraints, requirements and even who all the various role players are and what processes they are involved in. Following proper approaches (metamodels) when modelling, helps you identify what you otherwise might have missed completely, had you just focused on one element like process…

I’ve previously written more on this topic in the following BA Times article.

12- Be the glue

It could be argued that the best friend of the Project Manager is the Business Analyst. The PM’s role is to keep the ship headed in the right direction, delivery that project in time, on budget. But typically, they do not really have the luxury of getting involved in the details. This is where a good BA can add immense value to the Project Manager. Since we live in the details, The BA needs to constantly ensure alignment of understanding, expectations and communication between the various stakeholders. If anything tends to go even slightly off track, we are typically the first to sense it. 

Having this ground-level barometer could serve a Project Manager very well indeed. They could make quick course corrections or implement risk mitigations that could end up saving the project lots of time & money.

Since BA’s move vertically and horizontally across the entire organisation, we are in a unique position to have our ‘ears to the ground’ of everything that relates to a specific project. Our role therefore, is to be the glue. To constantly facilitate a coherent and aligned understanding. Facilitation is the name of the game. 

This facilitation should always be aimed at getting people to collaborate better. Constantly linking people and getting them to engage on issues of mutual interest, is key. “…people tend to support what they help create” – I read this somewhere years ago and can’t quite find who first coined this, but it really struck me, and I’ve personally found this to be true. 

Although this is much more difficult (and often slower) than not including numerous people into a session, this is the only true way to get broader buy-in and true collaboration when trying to introduce change. Like the old African saying goes: “If you want to go fast, go alone. If you want to go far, go together.”

So, remember to see yourself as the glue on a project, this has helped me on numerous occasions.

13- Be comfortable with uncertainty

Most Business Analysis is done in the context of something that needs to change. Sometimes what is currently there, needs to be improved or replaced or it simply is no longer fit for the future state of the organisation and needs to be transformed into something entirely different.

Whenever we walk through the doors on a new project, change is sure to follow, and this makes most people very uncomfortable indeed. Let’s face it, very few people like change. It creates uncertainty and uncertainty often generates a huge amount of fear. Will potential changes threaten people’s way of doing things, change their comfortable processes, possibly even affect their job security?

Developing soft skills, EQ and an understanding of how to work with people in a way that does not put additional stress on changing situations is critical. But the mindset you need to have as a person when it comes to your everyday headspace, is also important.

Besides handling changing organisational situations with the utmost sensitivity, we should also become comfortable with the fact that every day and every situation will probably differ from the previous. You might constantly find yourself out of your comfort zone, challenged with different new, unique sets of problems that you’ve never faced before. Such is the life of the BA. If this is not for you, where you’d prefer the predictability of every day being pretty much like the one before, then maybe you need to pursue a different career path.

Business Analysis is to constantly feel out of your comfort zone, but then again, outside your comfort zone, is the only place where one can truly grow, isn’t it?

14- Become a lifelong student

As I get older and especially in this information-bombardment-age that we live in, I constantly agree with the sentiment of the following quote (widely attributed by Albert Einstein): “The more I learn, the more I realize how much I don’t know.”

The simple truth is that none of us know it all and none of us can stay on top of everything that gets produced on a daily basis. Whether it is new research, inventions and discoveries, better methodologies or techniques, or even just new technologies or business models that severely disrupt the industries that we work in. But we have to do our best to try to keep up.

We have to commit to becoming lifelong students. We need to become ferocious readers. We need to accept the fact that having to learn new things every day, for the rest of your life, is now no longer an optional luxury, but rather a necessity, especially in the field of business analysis.

In doing this, we should not just focus on acquiring knowledge – this appears to have a rather limited shelf life and can become quickly outdated. Instead we must focus on acquiring true value-adding skills in the midst of ever-changing landscapes.

15- Measure impact & value

On numerous previous projects, I have found that whenever goals, successful outcomes, key performance indicators or metrics are not very clear, well-defined and written down, those objectives are very seldom achieved.

Clarifying metrics and success criteria, is some of the best questions a Business Analyst can ask at the onset of a project, in order to clarify what the required value add for a project will be. It creates clarity around the expectation and guides the team members towards what they need to work toward and clarity, creates purpose.

After doing this, it does of course help to create a baseline set of metrics, against which you can later measure any progress added as a direct result of the change initiative. 

“To measure is to know. If you can not measure it, you cannot improve it” – Lord Kelvin

16- Iterate 

Although the term ‘Agile’ has been overused, misquoted and sometimes even abused as a type of buzz-word over the last decade, no-one disputes the need for progress to happen faster, for business to be more adaptable and responsive to customer needs and for IT and product development teams to innovate as quickly and effectively as possible. 

I’ve personally learnt a lot about the freedom to “not have to have it perfect from the onset”. The gradual move away from factory-line ‘Big Design Up Front (BDUF)’ philosophies towards more emergent design strategies, makes a lot of sense, provided it is done properly.

Obviously, this does not mean that one:

  1. stops doing proper, professional analysis,
  2. lose track of the bigger picture,
  3. become a cowboy and reduce complex scenarios to a mere, oversimplified list of post-it notes

Instead it means that we adopt a different psychological mindset where we:

  • Accept that we don’t have all the answers up-front,
  • Make room for trial & error, failure (blasphemy!) and the ability to gradually improve our ideas,
  • Split complicated and gigantic pieces of work into bite-size chunks,
  • Have opportunities to change our minds,
  • Constantly engage with customers and stakeholder WHILE we create their world, so that by the product keeps on evolving while the world is changing,
  • We constantly ‘ship’ and deliver increments of value that is preferably sellable or useable whenever possible.

As a rather pragmatic person, being more agile has even helped me in my personal life to take more risks, become more creative and allow myself to make more mistakes. 

17- Remember you’ve got one of the best jobs in the world!

The idea that as a Business Analyst, I have one of the best jobs in the world, has been a revelation that I only gradually realised. And since that realisation, I’ve looked very differently at my job. 

Think about it…

Every single time you are confronted with long queues, inefficient systems, forms with redundant information, unnecessary procedures, frustrating IVR systems, poorly designed websites or phone apps, illogical (dumb?!) customer survey questionnaire, etc. this is as a direct result of poor business analysis.

As a Business Analyst, YOU CAN CHANGE THE WORLD – hopefully for the better!

The role of a Business Analyst allows you to:

  • Create new products, processes, systems, businesses
  • Change whatever is not working
  • Improve existing environments  Shape the world around you
  • Make things better
  • Truly add value

Since Business Analysis practices is not restricted to any specific industry or sphere in society, you can literally apply your skills wherever there are problems. And problems are everywhere…So, go-on, count yourself lucky to be a BA and go and make a real difference!

18- Details are key

The difference between a decent homemade Sunday afternoon dessert and an excellent homemade Sunday afternoon dessert, is often in the details of how it was made. The same is true for most things, also with respect to business and solution analysis.

I’ve learnt that I need to get comfortable with the fact that an excellent Business Analyst, needs to familiarise themselves extremely well with the details of what they are working on (perhaps even more so than any other project resource on a typical project team). This does mean lots and lots of reading, constant research, frequent and various meetings & workshops and daily documentation and/or modelling. 

But as Business Analyst, even though I might not be the Subject Matter Expert on every aspect of a project, I need to keep very close tabs on how everything fits together (Traceability), how requirements change over time (Requirements management) and how decisions and risks affect all the requirements and rules in the project (Impact management).

You want to become the go-to person, who has both a wide and a deep view of all aspects on a project.

The difference is in the details.

19- Take action! 

Oftentimes when we don’t know where to start, we get into a state of semi-paralysis and we don’t start. The longer we procrastinate, the more we seem to be unable to start. What I’ve learnt, is to JUST START.

Oftentimes, by just beginning, it somehow ‘loosens’ up new thoughts and ideas that then tend to lead you to the next step and then the next. 

Action begets action. Motion precedes emotion.

Take it from the inventor of the telephone, Alexander Graham Bell, who said: “The only difference between success and failure is the ability to take action.” 

20- Be yourself 

Besides all the wonderful best practices, methodologies, techniques, etc. that exist today, the fact is that no-one else on earth can bring exactly what YOU can bring…YOU. 

Your own unique ideas, perspectives and value. So, do NOT keep it to yourself!

You have been hired (and are being paid) to bring your uniqueness (who you are as well as your experiences) to your workplace and if you do not do this, it is not fair to those employing to do so.

You are unique and what you bring to the party is special – never forget this!

To-Do List/Ta-Da List

Being organised is an important aspect of business analysis, and so is personal reflection and maintaining motivation.

How can these aspects relate to each other?

To-do lists, whether mental, physical or digital (or a combination of all three!) form a key part of our strategy for ‘getting things done’, prioritising and feeling ‘on top of things’.

There is a sense of satisfaction in completing a task, and literally checking things off. That good feeling can be very fleeting, as we look with dismay at the many items remaining on the list, and we tend to take no time to reflect on the totality of things that have been checked-off.

A fact of modern life is that you will never reach the end of your to-do list!

Perhaps there is a way to maintain that sense of accomplishment, to create a lasting record of achievements and have somewhere to turn when a boost of motivation is needed.

When something is completed from your to-do list, take a couple of extra seconds to see if this should be moved to your ‘Ta-da’ list.

This may not be the ‘big-ticket’ items we can put on a CV, but the day-to-day activities we are getting through and instantly moving onto the next task. Items on the Ta-da list might include:

The positive things:

  • That was great
  • I surprised myself
  • I enjoyed that
  • I’m proud of that
  • I got great feedback.

The challenging things:

  • I thought it would take ages but it didn’t
  • I’ve been putting it off
  • I’ve never done it before
  • I was dreading it but it was fine
  • I was outside my comfort-zone, and I had to really push myself
  • It didn’t work out how I imagined, but I learned something.

Advertisement

The people things:

  • We worked really well together
  • I have a good relationship with that person now
  • I managed to influence that decision
  • I really helped that person
  • They really helped me.

The list may not turn out to be things you can easily articulate as achievements to other people (new job/promotion/bonus/award…) but will grow into a record of everyday activities and successes which would have been all too easily forgotten.

Manging to take note of even one item per month will yield a motivating list to look back on.

EXTENSION TO KANBAN

A physical or digital Kanban board gives us a shared record of what has been ‘Done’. This is a neutral list which does not draw attention to the things the team agree are the major achievements, these achievement’s may or may not reflect particularly significant or interesting features.  Extending Kanban to include ‘Ta-da’ moments keeps a celebratory list of the hurdles overcome, the good decisions made and the results that are achieved when the team is at its best.

CONCLUSION

In knowledge based and digital roles, it can often feel that all we ‘achieve’ day-to-day is meetings and emails. To keep up our motivation we need to record and reflect on our wins, successes and feel-good moments throughout the year.

As the year comes to a close, and we enter the new year with resolutions and good intentions, consider how you can make personal reflection part of your routine, as high up on your to-do list as being organised.

 

Further reading: Gretchen Rubin, Better Than Before (2016)

Five Trends in Business Analysis, Project Management, and Agile

Since 2009 we have enjoyed reflecting on what’s happened the previous year

in the world of projects and making predictions for the upcoming year. Here are some of the recent trend topics we have discussed:
  • The digital transformation
  • Roles that help organizations maximize value
  • Agile successes, challenges, and use beyond software 
  • Scaling agile 
  • BAs and PMs in the gig economy
Here are five industry trends that we have chosen for 2020:

BAs Helping Organizations Create Value-Driven AI Initiatives

Many organizations, around 72% according to Harvard Business Review, are finding that their AI initiatives are not meeting expectations,   There are many reasons for disappointing AI results, among them that many organizations:
  • Chase fascinating new technology with no clear vision of the business value (?) proposition
  • Focus on implementing the technology without considering how the organization will get and use the AI results
  • Mistakenly think that implementing AI projects will be easy
  • Seek to implement AI with antiquated and burdensome processes that do not support these initiatives
  • Ignore the immense cultural change needed to adopt AI technologies
Some organizations have turned to a role that is perfect for BAs and that can help organizations implement their AI initiatives. Although this role may or may not be called a BA, the work is definitely business analysis. This work includes:
  • Developing a business case to ensure there is value in undertaking the AI initiative
  • Reviewing the current state and recommending changes needed to existing processes, infrastructure, existing and needed data, and types of new roles and positions needed.
  • Recommending how to get everyone on board, given the enormity and difficulty with implementing this transformation. 

Advertisement

Product Owner Role Even More Challenging for BAs

An emerging trend is a recognition of the challenges faced when the business analyst (BA) plays the dual role of BA and product owner (PO) on Scrum teams. Here are some of those challenges: 
  • The PO role makes product decisions and sets backlog priorities. When there is no PO, a BA is often assigned as a “proxy” or “surrogate” PO. In this role they make decisions on product features and priorities. However, many BAs are finding that their proxy decisions are often overturned by the sponsor or other stakeholders causing rework and delays. 
  • The Product Owner (PO) role is accountable for quick and continuous delivery of value. The BA role is accountable for requirements. That is, for getting high-level user stories down to the details where they can be estimated and developed. This inherent conflict of getting it done quickly vs. getting it done right makes it difficult to play both roles at the same time. 
  • Some organizations understand the need for full-time POs on scrum teams. Because business stakeholders are unavailable, they assign the role to a BA. When the BA is accountable for the product, rather than being a trusted advisor, they end up “owning” the product and are often blamed if wrong decisions have been made.
We’re hearing more and more BAs speak out about these challenges and about the need for both POs and BAs on Agile projects. 

Putting a Little BA in Everyone’s Toolkit

Years ago, we watched project management evolve beyond the skillset expected of an individual with the title Project Manager (PM) into a core competency. It became expected not only of PMs, but of many middle managers even if they weren’t managing projects. 
In today’s product-focused organizations, we are seeing business analysis (BA) evolve in the same way. It seems that everyone is recognizing the value of enhancing their core skills with BA competencies. In today’s change-driven environments, where questions about what customers want and need are always top of mind, BA is used everywhere. So, it’s no surprise that we are increasingly seeing team members seek to augment their primary skillset with BA skills. 
Organizations are recognizing the benefits. They understand, however, that relying on just one or two individuals with the required BA skills is a recipe for gridlock. In addition to the obvious benefit of alleviating bottlenecks, developing fundamental BA skills in all team members also adds depth to their core skills. And we have recently observed workshop and conference participants, even those that do development work, become evangelists for adding a little BA to their toolkit. It does not get lost on them how some BA savvy is going to make them more effective when working with customers, product owners, and other team members. 

Digital Fluency and the Rise of the AI Translator

There are many ways for BAs to help organizations transform to the digital world and take advantage of AI and other digital technologies. Most of these ways require the BA to be a trusted advisor to the organization and help guide it in the right direction. However, to be a trusted advisor, BAs need to know what they’re talking about. They need to understand this complex world themselves. They need to be digitally fluent. 
Many organizations recognize that they need someone with this skillset to be successful. They are becoming aware of the importance of having someone who can translate the technical complexity of the AI world into business language. Someone who can help them articulate the results they want to achieve with their AI initiative. 
That’s why the title of AI Translator is receiving so much buzz. It’s a perfect role for the BA to fulfill, so look for more and more organization to use BAs in this translator role. 

Everyone But the BA Doing DevOps, But That Will Change

We’ve been writing about DevOps for several years, but it seems to us that its acceptance is just beginning to catch on. One of the main reasons that adoption has been slow is because many organizations don’t know what to make of it. They know DevOps supports continuous delivery, but continuous delivery is hard to define. 
Because DevOps means different things to different organizations, its implementation has been haphazard, and frequently does not include BAs. When we ask why, we often hear comments like, “Oh that’s just for Operations.” Or “Sure our organization has implemented DevOps, but it has nothing to do with us BAs.” Organizations understand that having continuous delivery of features does no good if implementing those features upsets the stability of the production environment. Which is what Dev Ops is all about. 
We think that organizations will soon recognize that BAs (and PMs) understand and are well-equipped to implement tools, foster collaborations, and facilitate cultural change, all of which are needed to support continuous delivery. So look for more and more organizations to include BAs in their DevOps adoption. 

By Elizabeth Larson, Andrea Brockmeier, Richard Larson

Andrea Brockmeier, PMP, CSM, PMI-ACP and PBA, is the Director of Project Management at Watermark Learning/PM Academy. She has 20+ years of experience in project management and related practice and training. She writes and teaches courses in project management, business analysis, and influencing skills.
Richard Larson, PMP, CBAP, PMI-PBA, Founder and former President of Watermark Learning, Richard Larson is a successful entrepreneur with over 35 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on BA and PM topics to over 10,000 participants on five different continents. Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, was a lead author for the Needs Assessment chapter of the PMI publication Business Analysis for Practitioners: A Practice Guide, and was an author of the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis.