Mastering Business Analysis - TopPodcast.com

Menu

Home
Top Charts
Top Networks
Top Apps
Top Independents
Top Podfluencers
Top Picks
Podcast News
About Us
Podcast Advertising
Contact

Not in our directory?
Add Show Here

Podcast Equipment
Center

Our TOPPODCAST Picks

Comedy
Crypto
Sports
News
Politics
True Crime
Business
Finance

Follow Us

Stay Connected

View Top 200 Chart

Back to Rankings Page

Mastering Business Analysis — Education
Mastering Business Analysis

Your key to advancing your career as a Business Analyst and beyond

Copyright: © MasterClass 247 LLC

Latest Episodes:

Steve Blais — MBA126: Guiding Principles for the Business Analyst May 30, 2017
Show notes

In this episode, author and consultant Steve Blais shares with us his 11 principles of the business analyst, which provides guidance as to what a business analyst should do to achieve success.

This is part 1 of a 2 part episode. The interview was longer than my usual episodes and full of such great information that I decided to split it into two episodes. You can listen to part two in episode 127.

After listening to this episode, you'll understand:

What a Business Analyst truly is

Why you should focus on the product instead of the project

Users don’t have requirements (and what that means for you)

How focusing on individual SMEs can lead to problems


Show Notes

The concept of a Business Analyst as a position is somewhat constraining. A person doing business analysis is not necessarily someone creating software requirements, but one who solves problems for the business.

Regardless of your role title, there are certain guiding principles that lead to success.

Principle 1: Focus on the Product

So often we focus on the solution; how the software will be written, the project timeline, and the budget. Instead, we should focus on the product, not the project.

The product exists whether you make changes to it or not. By focusing on the product, we can focus on the problem domain instead of getting caught up in the particulars of the project.

This mindset shift also helps you to see the impact that a change to a product will have on the people and processes. You also will consider the value of the change before you start to determine if it’s worth doing.

Principle 2: First Define the Problem, then the Solution

We are frequently given a solution to implement instead of a problem to be solved. But how do we know if it’s the right solution if we don’t understand the problem?

To combat this problem, ask ‘why’ when we’re given a solution. Before you implement a solution, make sure you’re solving the right problem.

Principle 3: Users Don’t Have Requirements

Users and stakeholders don’t have requirements. All they have is information.

We need to elicit that information and analyze it within the context of the problem to determine the requirements. Remember that requirements don’t exist until we analyze them into existence.

This mindset shift alleviates some of the main complaints from Business Analysts; namely the business doesn’t know what they want and the requirements keep changing.

Principle 4: Focus on Information, Not Individuals

Instead of following the trail of subject matter experts (SMEs) to get answers, first determine the information you need to solve the problem. Then find out how to get that information.

This solves the problem of biases toward a particular area and delays due to lack of availability of SMEs.

Listen to the full episode to hear about what a Business Analyst actually is and how to apply the guiding principles.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA126.mp3

Be sure to check out episode 127 for the second half of this interview and to hear the remaining 7 principles.

Links mentioned in this episode:

Steve’s website EssenceoftheBA.com

Get Steve’s book, Business Analysis: Best Practices for Success

Part 2 of my interview with Steve

Steve Blais

Author and Consultant

Steve Blais is an author and consultant with almost 50 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. Steve was on the committee for the IIBA’s BABOK Guide version 3.0 and is the author of Business Analysis: Best Practices for Success.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA126: Guiding Principles for the Business Analyst appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA126: Guiding Principles for the Business Analyst May 30, 2017
Show notes

In this episode, author and consultant Steve Blais shares with us his 11 principles of the business analyst, which provides guidance as to what a business analyst should do to achieve success.

This is part 1 of a 2 part episode. The interview was longer than my usual episodes and full of such great information that I decided to split it into two episodes. You can listen to part two in episode 127.

After listening to this episode, you'll understand:

What a Business Analyst truly is

Why you should focus on the product instead of the project

Users don’t have requirements (and what that means for you)

How focusing on individual SMEs can lead to problems


Show Notes

The concept of a Business Analyst as a position is somewhat constraining. A person doing business analysis is not necessarily someone creating software requirements, but one who solves problems for the business.

Regardless of your role title, there are certain guiding principles that lead to success.

Principle 1: Focus on the Product

So often we focus on the solution; how the software will be written, the project timeline, and the budget. Instead, we should focus on the product, not the project.

The product exists whether you make changes to it or not. By focusing on the product, we can focus on the problem domain instead of getting caught up in the particulars of the project.

This mindset shift also helps you to see the impact that a change to a product will have on the people and processes. You also will consider the value of the change before you start to determine if it’s worth doing.

Principle 2: First Define the Problem, then the Solution

We are frequently given a solution to implement instead of a problem to be solved. But how do we know if it’s the right solution if we don’t understand the problem?

To combat this problem, ask ‘why’ when we’re given a solution. Before you implement a solution, make sure you’re solving the right problem.

Principle 3: Users Don’t Have Requirements

Users and stakeholders don’t have requirements. All they have is information.

We need to elicit that information and analyze it within the context of the problem to determine the requirements. Remember that requirements don’t exist until we analyze them into existence.

This mindset shift alleviates some of the main complaints from Business Analysts; namely the business doesn’t know what they want and the requirements keep changing.

Principle 4: Focus on Information, Not Individuals

Instead of following the trail of subject matter experts (SMEs) to get answers, first determine the information you need to solve the problem. Then find out how to get that information.

This solves the problem of biases toward a particular area and delays due to lack of availability of SMEs.

Listen to the full episode to hear about what a Business Analyst actually is and how to apply the guiding principles.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA126.mp3

Be sure to check out episode 127 for the second half of this interview and to hear the remaining 7 principles.

Links mentioned in this episode:

Steve’s website EssenceoftheBA.com

Get Steve’s book, Business Analysis: Best Practices for Success

Part 2 of my interview with Steve

Steve Blais

Author and Consultant

Steve Blais is an author and consultant with almost 50 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. Steve was on the committee for the IIBA’s BABOK Guide version 3.0 and is the author of Business Analysis: Best Practices for Success.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA126: Guiding Principles for the Business Analyst appeared first on Mastering Business Analysis.

Ian Huke — MBA125: Become the Conscience of the Business May 23, 2017
Show notes

In this episode, Ian Huke helps us to become the conscience of the business by doing the right thing, building a following, and becoming a trusted advisor.

After listening to this episode, you'll understand:

Why the BA is positioned to become the conscience of the business

How you can avoid pet projects and local optimization

Ways to gather a following and create a movement


Show Notes

As Business Analysts, we have an obligation to ensure the success of not only the project, but also the organization.

Unfortunately, many organizations are plagued by pet projects which are of little value or projects that optimize one area at the expense of another. Many projects are pushed forward without a strong business case behind it.

While everyone in the organization should be responsible for ensuring we do the right things and drive forward with the right initiatives, BAs are uniquely positioned to have line of sight to understand value. This allows us to influence the organization in the pre-project phase and advise at a strategic level.

Through being a trusted advisor, we can become the conscience on the business.

What’s Holding Us Back?

There are a number of factors that hold us back from influencing the organization to avoid or stop projects with little or no value.

First, it’s difficult for people to challenge organizations and leaders. It takes courage to push back when we feel that a project has no merit.

Another factor preventing us from becoming the conscience of the business and advising the organization is the need for permission. We often feel that we need permission to make such recommendations.

Culture certainly plays a role in the hesitancy to speak up. In some organizations, it’s inappropriate for people in lower level roles to speak to leaders.

Becoming the Voice of Reason

There are a number of ways we can find legitimacy in making the challenge to leadership about these projects.

Is there something in your job description (actual or implied) about ensuring successful outcomes? If so, that’s your opportunity to put your challenge into context; that you’re trying to ensure successful outcomes.

Another opportunity is to try to trace the project back to the organization’s mission and vision. You can question how the project aligns with or moves us closer to that mission.

Build a Following

You can build support for your cause by developing your leadership skills and building a following. Having a group of supporters behind you allows you to gain momentum and influence change.

To build a following, first work to understand the needs of those you’re trying to influence and try to meet those needs. Their needs may be achieved within the project or possibly personal needs.

Recognize that you can build your followers over time and at lower levels; you don’t need to start with leaders.
How to Start a Movement TED Talk

Listen to the full episode to understand how to be the conscience of the business and build your influencing skills by building a following.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA125.mp3
Z
Your Homework

Take time to think about who your current followers are. Then, consider who you need behind you to influence the organization and work to gain a following in those areas.

Links mentioned in this episode:

Ian’s website Build-BA.com

Ian’s article on LinkedIn

Ian Huke

Consultant, Business Analyst

Ian provides interim management and consulting services focused on leading and managing change professionals. His expertise covers developing internal change capabilities, evaluating new change initiatives, and stabilizing in-flight programs.

Ian also works with organizations to enhance their business analysis capabilities by addressing individual competencies and pre and post project outcomes.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA125: Become the Conscience of the Business appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA125: Become the Conscience of the Business May 23, 2017
Show notes

In this episode, Ian Huke helps us to become the conscience of the business by doing the right thing, building a following, and becoming a trusted advisor.

After listening to this episode, you'll understand:

Why the BA is positioned to become the conscience of the business

How you can avoid pet projects and local optimization

Ways to gather a following and create a movement


Show Notes

As Business Analysts, we have an obligation to ensure the success of not only the project, but also the organization.

Unfortunately, many organizations are plagued by pet projects which are of little value or projects that optimize one area at the expense of another. Many projects are pushed forward without a strong business case behind it.

While everyone in the organization should be responsible for ensuring we do the right things and drive forward with the right initiatives, BAs are uniquely positioned to have line of sight to understand value. This allows us to influence the organization in the pre-project phase and advise at a strategic level.

Through being a trusted advisor, we can become the conscience on the business.

What’s Holding Us Back?

There are a number of factors that hold us back from influencing the organization to avoid or stop projects with little or no value.

First, it’s difficult for people to challenge organizations and leaders. It takes courage to push back when we feel that a project has no merit.

Another factor preventing us from becoming the conscience of the business and advising the organization is the need for permission. We often feel that we need permission to make such recommendations.

Culture certainly plays a role in the hesitancy to speak up. In some organizations, it’s inappropriate for people in lower level roles to speak to leaders.

Becoming the Voice of Reason

There are a number of ways we can find legitimacy in making the challenge to leadership about these projects.

Is there something in your job description (actual or implied) about ensuring successful outcomes? If so, that’s your opportunity to put your challenge into context; that you’re trying to ensure successful outcomes.

Another opportunity is to try to trace the project back to the organization’s mission and vision. You can question how the project aligns with or moves us closer to that mission.

Build a Following

You can build support for your cause by developing your leadership skills and building a following. Having a group of supporters behind you allows you to gain momentum and influence change.

To build a following, first work to understand the needs of those you’re trying to influence and try to meet those needs. Their needs may be achieved within the project or possibly personal needs.

Recognize that you can build your followers over time and at lower levels; you don’t need to start with leaders.
How to Start a Movement TED Talk

Listen to the full episode to understand how to be the conscience of the business and build your influencing skills by building a following.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA125.mp3
Z
Your Homework

Take time to think about who your current followers are. Then, consider who you need behind you to influence the organization and work to gain a following in those areas.

Links mentioned in this episode:

Ian’s website Build-BA.com

Ian’s article on LinkedIn

Ian Huke

Consultant, Business Analyst

Ian provides interim management and consulting services focused on leading and managing change professionals. His expertise covers developing internal change capabilities, evaluating new change initiatives, and stabilizing in-flight programs.

Ian also works with organizations to enhance their business analysis capabilities by addressing individual competencies and pre and post project outcomes.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA125: Become the Conscience of the Business appeared first on Mastering Business Analysis.

Lynda Girvan — MBA124: Business Analyst in an Agile Environment May 16, 2017
Show notes

In this episode, author Lynda Girvan discusses how BAs can succeed in Agile environments by applying a lean and adaptive approach.

After listening to this episode, you'll understand:

How to make your BA process more Agile

The three ways of thinking that lead to success in Agile

The difference between real Agile and a series of small waterfalls


Show Notes

Do we need Business Analysts in Agile? It depends.

The skill of analysis is certainly needed in Agile product development. Either the people within the team need to develop their business analysis skills or the Business Analyst needs to become more “T” shaped.

Outside of product development, specialized Business Analysts can contribute even in Agile environments.

The Agile Business Analyst

Business Analysts in an agile environment do many of the same things that they do in a traditional waterfall environment, just with a different mindset.

You still create models, but do just enough just in time instead of creating everything upfront. You still document information, but do so with a service thinking approach.

The skills that you’ve developed as a traditional BA are still valuable in Agile if you apply an Agile mindset. The Agile mindset includes Lean thinking, service thinking, and systems thinking.

Lean Thinking

Lean is about reducing waste to deliver value. There can be a lot of waste in traditional business analysis activities and Lean thinking seeks to reduce that waste.

One form of waste is overproduction. When we create monolithic requirements documents (many features of which are never used), that’s a form of overproduction.

Over processing is another form of waste. This is seen when we provide more detail that is needed.

Partially done work (e.g., incomplete models or those that don’t provide value) is another form of waste because this becomes inventory that we now need to store and maintain.

Service Thinking

Service thinking is the concept that we can’t deliver value. We can only propose value. Once we deliver something, we can get feedback from the customer to determine if it was of value to them.

If we understand that concept, we can get into value co-creation. This is when we understand who the customer is and understand what their needs are and what’s valuable to them.

Value co-creation involves tight collaboration between the team and customers.

Systems Thinking

Systems thinking is about being able to see all of the interrelated parts. These parts need to work together.

This approach helps you to avoid silos. Systems thinking also helps you to understand how changes to one part of the system affect other parts.

Agile teams often focus on one product and fail to see the wider implications across the organization.

All of these concepts lead to one thing: Shortening the loop between concept and delivery. Requirements are just a means to an end. We need to figure out how to analyze just enough to deliver something and get feedback so we can learn and adapt.

Listen to the full episode for more on how to prioritize work, the difference between Agile and a series of small waterfall efforts, how to make your requirements more agile, and how to succeed in an Agile environment.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA124.mp3
Z
Your Homework

Start being Agile

Apply Agile as a mindset. Think about how you can apply Lean thinking, service thinking, and systems thinking to your work. Forget about frameworks and start being agile.

Links mentioned in this episode:

Lynda’s website Agile-Analysis.co.uk

Assist Knowledge Development website

Get Lynda’s book for 25% off at the BCS Shop. Use discount code agilebamaster17

Lynda Girvan

Principal Consultant and Trainer

Lynda Girvan is a Principal Consultant and Trainer for Assist Knowledge Development. She has over 25 years experience in business analysis, agile development, agile coaching and transformational change programs.

Lynda is also a mentor for the BCS International Diploma in Business Analysis and co-authored the book Agile and Business Analysis.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA124: Business Analyst in an Agile Environment appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA124: Business Analyst in an Agile Environment May 16, 2017
Show notes

In this episode, author Lynda Girvan discusses how BAs can succeed in Agile environments by applying a lean and adaptive approach.

After listening to this episode, you'll understand:

How to make your BA process more Agile

The three ways of thinking that lead to success in Agile

The difference between real Agile and a series of small waterfalls


Show Notes

Do we need Business Analysts in Agile? It depends.

The skill of analysis is certainly needed in Agile product development. Either the people within the team need to develop their business analysis skills or the Business Analyst needs to become more “T” shaped.

Outside of product development, specialized Business Analysts can contribute even in Agile environments.

The Agile Business Analyst

Business Analysts in an agile environment do many of the same things that they do in a traditional waterfall environment, just with a different mindset.

You still create models, but do just enough just in time instead of creating everything upfront. You still document information, but do so with a service thinking approach.

The skills that you’ve developed as a traditional BA are still valuable in Agile if you apply an Agile mindset. The Agile mindset includes Lean thinking, service thinking, and systems thinking.

Lean Thinking

Lean is about reducing waste to deliver value. There can be a lot of waste in traditional business analysis activities and Lean thinking seeks to reduce that waste.

One form of waste is overproduction. When we create monolithic requirements documents (many features of which are never used), that’s a form of overproduction.

Over processing is another form of waste. This is seen when we provide more detail that is needed.

Partially done work (e.g., incomplete models or those that don’t provide value) is another form of waste because this becomes inventory that we now need to store and maintain.

Service Thinking

Service thinking is the concept that we can’t deliver value. We can only propose value. Once we deliver something, we can get feedback from the customer to determine if it was of value to them.

If we understand that concept, we can get into value co-creation. This is when we understand who the customer is and understand what their needs are and what’s valuable to them.

Value co-creation involves tight collaboration between the team and customers.

Systems Thinking

Systems thinking is about being able to see all of the interrelated parts. These parts need to work together.

This approach helps you to avoid silos. Systems thinking also helps you to understand how changes to one part of the system affect other parts.

Agile teams often focus on one product and fail to see the wider implications across the organization.

All of these concepts lead to one thing: Shortening the loop between concept and delivery. Requirements are just a means to an end. We need to figure out how to analyze just enough to deliver something and get feedback so we can learn and adapt.

Listen to the full episode for more on how to prioritize work, the difference between Agile and a series of small waterfall efforts, how to make your requirements more agile, and how to succeed in an Agile environment.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA124.mp3
Z
Your Homework

Start being Agile

Apply Agile as a mindset. Think about how you can apply Lean thinking, service thinking, and systems thinking to your work. Forget about frameworks and start being agile.

Links mentioned in this episode:

Lynda’s website Agile-Analysis.co.uk

Assist Knowledge Development website

Get Lynda’s book for 25% off at the BCS Shop. Use discount code agilebamaster17

Lynda Girvan

Principal Consultant and Trainer

Lynda Girvan is a Principal Consultant and Trainer for Assist Knowledge Development. She has over 25 years experience in business analysis, agile development, agile coaching and transformational change programs.

Lynda is also a mentor for the BCS International Diploma in Business Analysis and co-authored the book Agile and Business Analysis.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA124: Business Analyst in an Agile Environment appeared first on Mastering Business Analysis.

Kitty Hass — MBA123: The 21st Century Business Analyst May 09, 2017
Show notes

In this episode, Kitty Hass explains the evolution of the Business Analyst role and what you need to do to be successful in the 21st century.

After listening to this episode, you'll understand:

How the BA role has evolved in the last 20 years

Why the typical task of documenting requirements is no longer enough

What skills you need to be successful in today’s complex environment


Show Notes

In the later part of the 20^th century, Business Analysts were looked upon as team members. They were certainly not seen as leaders.

It was seen as a tactical role and BAs spent most of their time analyzing and documenting requirements.

The amount of time spent on strategic analysis, competitive analysis, and facilitating discussions on how the organization can innovate was less than 10% of their time.

Being seen only as a documenter is demoralizing and limits the value that a BA can bring to the organization.

The linear, waterfall approach at that time assumed we were smart enough to define all of the requirements upfront. The methods we were using were deficient for the complex, fast-changing environment we were in.

The Real Problem

It’s not just on time and on scope for a project anymore.

We’re less than 30% successful in our projects in terms or on time, on budget, and with a satisfactory result. The cause is twofold; we have gaps in strategic, value based business analysis and we have gaps in complex project management.

Shoring up these gaps can add countless wasted dollars to the bottom line.

The Challenge of the 21^st Century

The 21^st Century challenges us to change. With the growing complexity of today’s business and technological environments, we can’t influence positive change without bringing together differing points of view.

We need to move out of our past tactical role and focus more on strategic level thinking across the organization. This requires an understanding of the business domain and the changing business environment.

We also need to shift our communication style (both verbal and written) to a more collaborative and iterative style. Focus less on large, complex documentation and more on just enough to develop a shared understanding.

The International Institute for Business Analysis (IIBA) issued a research and impact study in 2016 that showed the evolving role of the Business Analyst. The study showed that we need to evolve from requirements manager and documenter to Agile adaptive adoption and innovation influencer.

The skills that you will need over the next three to five years are strategic thinking, strategic analysis, leadership, creativity, and innovative thinking. Additionally, you’ll need your current sills of critical thinking, domain knowledge, competitive awareness, investigative techniques, and knowledge of technology your organization uses.

Radical Collaboration

Don’t underestimate the power of collaboration. You are expected to be able to bring together a group of smart people to solve big problems.

You must be able to get the right experts in the room and know how to facilitate a discussion to understand the opportunity and determine the path forward.

Listen to the full episode to discover what organizations need and how to be successful in the 21st century.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA123.mp3
Z
Your Homework

Your job is to manage the value of what you’re delivering. For each release, you should understand the cost, the value to the customer, and how we’re going to measure success. This includes having an overall business case for the effort.

Focus your development on leadership, innovation, and understanding the new enterprise roles.

Links mentioned in this episode:

Kitty’s Website – Kathleen Hass & Associates

Kitty’s books on Amazon

Kitty Hass

Kathleen Hass and Associates, Inc.

Kitty Hass is the leading expert in Strategic Business Analysis and Complex Project Management. She has written nine books, dozens of influential articles, and given lectures at corporations throughout the world. She is a professor of Strategic PM and BA Practices at Villanova University and a keynote speaker at conferences around the world.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA123: The 21st Century Business Analyst appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA123: The 21st Century Business Analyst May 09, 2017
Show notes

In this episode, Kitty Hass explains the evolution of the Business Analyst role and what you need to do to be successful in the 21st century.

After listening to this episode, you'll understand:

How the BA role has evolved in the last 20 years

Why the typical task of documenting requirements is no longer enough

What skills you need to be successful in today’s complex environment


Show Notes

In the later part of the 20^th century, Business Analysts were looked upon as team members. They were certainly not seen as leaders.

It was seen as a tactical role and BAs spent most of their time analyzing and documenting requirements.

The amount of time spent on strategic analysis, competitive analysis, and facilitating discussions on how the organization can innovate was less than 10% of their time.

Being seen only as a documenter is demoralizing and limits the value that a BA can bring to the organization.

The linear, waterfall approach at that time assumed we were smart enough to define all of the requirements upfront. The methods we were using were deficient for the complex, fast-changing environment we were in.

The Real Problem

It’s not just on time and on scope for a project anymore.

We’re less than 30% successful in our projects in terms or on time, on budget, and with a satisfactory result. The cause is twofold; we have gaps in strategic, value based business analysis and we have gaps in complex project management.

Shoring up these gaps can add countless wasted dollars to the bottom line.

The Challenge of the 21^st Century

The 21^st Century challenges us to change. With the growing complexity of today’s business and technological environments, we can’t influence positive change without bringing together differing points of view.

We need to move out of our past tactical role and focus more on strategic level thinking across the organization. This requires an understanding of the business domain and the changing business environment.

We also need to shift our communication style (both verbal and written) to a more collaborative and iterative style. Focus less on large, complex documentation and more on just enough to develop a shared understanding.

The International Institute for Business Analysis (IIBA) issued a research and impact study in 2016 that showed the evolving role of the Business Analyst. The study showed that we need to evolve from requirements manager and documenter to Agile adaptive adoption and innovation influencer.

The skills that you will need over the next three to five years are strategic thinking, strategic analysis, leadership, creativity, and innovative thinking. Additionally, you’ll need your current sills of critical thinking, domain knowledge, competitive awareness, investigative techniques, and knowledge of technology your organization uses.

Radical Collaboration

Don’t underestimate the power of collaboration. You are expected to be able to bring together a group of smart people to solve big problems.

You must be able to get the right experts in the room and know how to facilitate a discussion to understand the opportunity and determine the path forward.

Listen to the full episode to discover what organizations need and how to be successful in the 21st century.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA123.mp3
Z
Your Homework

Your job is to manage the value of what you’re delivering. For each release, you should understand the cost, the value to the customer, and how we’re going to measure success. This includes having an overall business case for the effort.

Focus your development on leadership, innovation, and understanding the new enterprise roles.

Links mentioned in this episode:

Kitty’s Website – Kathleen Hass & Associates

Kitty’s books on Amazon

Kitty Hass

Kathleen Hass and Associates, Inc.

Kitty Hass is the leading expert in Strategic Business Analysis and Complex Project Management. She has written nine books, dozens of influential articles, and given lectures at corporations throughout the world. She is a professor of Strategic PM and BA Practices at Villanova University and a keynote speaker at conferences around the world.

LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA123: The 21st Century Business Analyst appeared first on Mastering Business Analysis.

Alaeddin Hallak, CBAP — MBA122: Driving Real Value Through Business Analysis May 02, 2017
Show notes

In this episode, Alaeddin Hallak shows us how to deliver real business value through our business analysis approach.

After listening to this episode, you'll understand:

How to determine what value really means

Why you should focus on outcomes instead of outputs

Approaches you can use to contribute more value to your organization


Show Notes

What exactly is business value? We as Business Analysts help our organizations realize business value when we do things that either sustain or increase revenue or reduce/avoid cost.

Increasing revenue and avoiding cost are top level measures of business value. Things like increase market share, customer satisfaction, quality, and compliance with regulations lead to these top level business value outcomes.

Why Should Business Analysts Be Concerned About Value?

Business value isn’t just the realm of project sponsors. Customers expect more and the environment is changing quickly.

To stay competitive, we need to produce more value with the same resources. If we do, we’ll not just stay relevant, but also prosper.

We need to take more ownership in driving business value.

Focus on Business Value

It all starts with a mindset shift. We need to realize that outcomes are more important than outputs. We should also understand that we’re here to create products that solve problems, not just participate on projects.

Observe what you’re doing and ask yourself “Will what I’m doing right now generate more business value?” Can business objectives be traced back to what you’re doing?

This mindset shift starts with having knowledge of the business. From there, you can apply concepts such as design thinking to ensure you understand customers and deliver the right solutions.

How Can We Add Value?

Before you attempt to formulate a solution, you need to thoroughly understand the business problem. Failing to do so leads to wasted time and resources.

Have a skeptical mindset when given a solution. You can apply tools such as root cause analysis, design thinking, contextual observation, and benchmarking to help focus on the right problem to solve.

As change agents, we need to go the extra mile and help the organizations adopt the changes we implement. Involving stakeholders and end users early leads to more ownership, less resistance, and better adoption of the change.

Listen to the full episode to find out how to seek positive outcomes, why Agile is an ‘undo’ button, and what to do when you’re handed a solution to implement.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA122.mp3
Z
Your Homework

Brainstorm ideas about what it would take for your organization to adopt the change you’re currently working on.
Are there transition requirements that you haven’t considered?
What’s your sense from stakeholders about how people will receive the change?
If you feel there will be resistance, what can you do to evangilize the benefits of the change or raise the issue to leaders?

Links mentioned in this episode:

Alaeddin’s website LeanBA.me

The BA Learning Program Learn.ba/mba

Alaeddin Hallak, CBAP

Senior Business Analyst

Alaeddin is a multidisciplinary Senior Business Analyst with a relentless focus on delivering valuable business outcomes and eliminating waste. He has over 12 years’ experience in being a change agent in sectors such as IT, finance, and government. Alaeddin is on a mission to solve business problems with solutions that balance business value, UX, and technical feasibility.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA122: Driving Real Value Through Business Analysis appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA122: Driving Real Value Through Business Analysis May 02, 2017
Show notes

In this episode, Alaeddin Hallak shows us how to deliver real business value through our business analysis approach.

After listening to this episode, you'll understand:

How to determine what value really means

Why you should focus on outcomes instead of outputs

Approaches you can use to contribute more value to your organization


Show Notes

What exactly is business value? We as Business Analysts help our organizations realize business value when we do things that either sustain or increase revenue or reduce/avoid cost.

Increasing revenue and avoiding cost are top level measures of business value. Things like increase market share, customer satisfaction, quality, and compliance with regulations lead to these top level business value outcomes.

Why Should Business Analysts Be Concerned About Value?

Business value isn’t just the realm of project sponsors. Customers expect more and the environment is changing quickly.

To stay competitive, we need to produce more value with the same resources. If we do, we’ll not just stay relevant, but also prosper.

We need to take more ownership in driving business value.

Focus on Business Value

It all starts with a mindset shift. We need to realize that outcomes are more important than outputs. We should also understand that we’re here to create products that solve problems, not just participate on projects.

Observe what you’re doing and ask yourself “Will what I’m doing right now generate more business value?” Can business objectives be traced back to what you’re doing?

This mindset shift starts with having knowledge of the business. From there, you can apply concepts such as design thinking to ensure you understand customers and deliver the right solutions.

How Can We Add Value?

Before you attempt to formulate a solution, you need to thoroughly understand the business problem. Failing to do so leads to wasted time and resources.

Have a skeptical mindset when given a solution. You can apply tools such as root cause analysis, design thinking, contextual observation, and benchmarking to help focus on the right problem to solve.

As change agents, we need to go the extra mile and help the organizations adopt the changes we implement. Involving stakeholders and end users early leads to more ownership, less resistance, and better adoption of the change.

Listen to the full episode to find out how to seek positive outcomes, why Agile is an ‘undo’ button, and what to do when you’re handed a solution to implement.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA122.mp3
Z
Your Homework

Brainstorm ideas about what it would take for your organization to adopt the change you’re currently working on.
Are there transition requirements that you haven’t considered?
What’s your sense from stakeholders about how people will receive the change?
If you feel there will be resistance, what can you do to evangilize the benefits of the change or raise the issue to leaders?

Links mentioned in this episode:

Alaeddin’s website LeanBA.me

The BA Learning Program Learn.ba/mba

Alaeddin Hallak, CBAP

Senior Business Analyst

Alaeddin is a multidisciplinary Senior Business Analyst with a relentless focus on delivering valuable business outcomes and eliminating waste. He has over 12 years’ experience in being a change agent in sectors such as IT, finance, and government. Alaeddin is on a mission to solve business problems with solutions that balance business value, UX, and technical feasibility.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA122: Driving Real Value Through Business Analysis appeared first on Mastering Business Analysis.

Geoff Watts — MBA121: Mastering Product Ownership Apr 25, 2017
Show notes

In this episode, Geoff Watts helps us to better understand the Product Owner role and takes us from good to great product ownership.

After listening to this episode, you'll understand:

If someone can be both a Business Analyst and a Product Owner

Why Product Owners must be DRIVEN

How to go from good to great product ownership


Show Notes

The Product Owner role is a difficult role to fulfill. There are deep responsibilities and doing the job well requires multiple different areas of skill and knowledge.

Is the Business Analyst a Product Owner?

Product Owners require a certain amount of analysis to be successful. They are informed about their product, their customers, how the product will be used, and the business environment. They also need to pass that knowledge along to the people developing the product.

Product Owners don’t necessarily need to do all of that themselves. Whether or not other members of the team (such as Business Analysts or developers) help them in analysis and understanding of the customers depends on the context.

One key distinction between a Business Analyst and a Product Owner is that Product Owners have decision making authority. Business Analysts often help business representatives make the right decisions, but have no decision making authority themselves.

What Makes a Great Product Owner

The best Product Owners are driven. They’re passionate about their product and the customers. As they encounter challenges, they need to put their heart into in and overcome obsticles.

The acronym DRIVEN can also be used to describe the characteristics of a great Product Owner.

D stands for Decisive. Product Owners need to make a lot of decisions and often those decisions need to be made with incomplete information.

R stands for Ruthless. Being ruthless is about understanding what value means for your product and focusing on only things that add value. Great Product Owners are also ruthless about minimizing risk.

I stands for Informed. Product Owners are naturally curious and will do a certain amount of research and analysis. This allows them to make good decisions even in times of uncertainty.

V stands for versatile. They are versatile in their leadership style. This allows Product Owners to provide a sense of stability in times of anxiety when circumstances change.

E stands for empowering. The best Product Owners lead from within rather from the front. They also include relevant parties in discussions and decision making. They delegate authority appropriately.

N stands for Negotiable. Great Product Owners bring people together and work to understand all perspectives. They also trade off priorities with needed.

Listen to the full episode to understand how these characteristics are linked, what to do about analysis paralysis, which area Product Owners struggle with the most, and what you can do to address those struggles.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA121.mp3
Z
Your Homework

Practice mindfulness. Use some self-reflection and self-analysis. Reflect on your effectiveness and what’s making your job more difficult than it should be. Then focus on what’s in your area of control.

Finally, ask yourself if you’re making any assumptions about your situation that may not be true.

Links mentioned in this episode:

Geoff’s website Inspect and Adapt

Geoff’s book, Product Mastery

Geoff Watts

Founder, Inspect & Adapt Ltd.

Geoff Watts is the founder of Inspect & Adapt Ltd. and one of the most experienced and respected Scrum coaches in the world.
Having started using Scrum at British Telecom, one of the first large-scale agile adoptions, he has since coached organisations large and small through their agile journeys. Goeff is also an inspirational speaker and author.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA121: Mastering Product Ownership appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA121: Mastering Product Ownership Apr 25, 2017
Show notes

In this episode, Geoff Watts helps us to better understand the Product Owner role and takes us from good to great product ownership.

After listening to this episode, you'll understand:

If someone can be both a Business Analyst and a Product Owner

Why Product Owners must be DRIVEN

How to go from good to great product ownership


Show Notes

The Product Owner role is a difficult role to fulfill. There are deep responsibilities and doing the job well requires multiple different areas of skill and knowledge.

Is the Business Analyst a Product Owner?

Product Owners require a certain amount of analysis to be successful. They are informed about their product, their customers, how the product will be used, and the business environment. They also need to pass that knowledge along to the people developing the product.

Product Owners don’t necessarily need to do all of that themselves. Whether or not other members of the team (such as Business Analysts or developers) help them in analysis and understanding of the customers depends on the context.

One key distinction between a Business Analyst and a Product Owner is that Product Owners have decision making authority. Business Analysts often help business representatives make the right decisions, but have no decision making authority themselves.

What Makes a Great Product Owner

The best Product Owners are driven. They’re passionate about their product and the customers. As they encounter challenges, they need to put their heart into in and overcome obsticles.

The acronym DRIVEN can also be used to describe the characteristics of a great Product Owner.

D stands for Decisive. Product Owners need to make a lot of decisions and often those decisions need to be made with incomplete information.

R stands for Ruthless. Being ruthless is about understanding what value means for your product and focusing on only things that add value. Great Product Owners are also ruthless about minimizing risk.

I stands for Informed. Product Owners are naturally curious and will do a certain amount of research and analysis. This allows them to make good decisions even in times of uncertainty.

V stands for versatile. They are versatile in their leadership style. This allows Product Owners to provide a sense of stability in times of anxiety when circumstances change.

E stands for empowering. The best Product Owners lead from within rather from the front. They also include relevant parties in discussions and decision making. They delegate authority appropriately.

N stands for Negotiable. Great Product Owners bring people together and work to understand all perspectives. They also trade off priorities with needed.

Listen to the full episode to understand how these characteristics are linked, what to do about analysis paralysis, which area Product Owners struggle with the most, and what you can do to address those struggles.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA121.mp3
Z
Your Homework

Practice mindfulness. Use some self-reflection and self-analysis. Reflect on your effectiveness and what’s making your job more difficult than it should be. Then focus on what’s in your area of control.

Finally, ask yourself if you’re making any assumptions about your situation that may not be true.

Links mentioned in this episode:

Geoff’s website Inspect and Adapt

Geoff’s book, Product Mastery

Geoff Watts

Founder, Inspect & Adapt Ltd.

Geoff Watts is the founder of Inspect & Adapt Ltd. and one of the most experienced and respected Scrum coaches in the world.
Having started using Scrum at British Telecom, one of the first large-scale agile adoptions, he has since coached organisations large and small through their agile journeys. Goeff is also an inspirational speaker and author.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA121: Mastering Product Ownership appeared first on Mastering Business Analysis.

Alan Klement — MBA120: Jobs to be Done Theory Apr 18, 2017
Show notes

In this episode, Alan Klement shows us how Jobs to be Done can help you design better products and spur innovation. Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love.

After listening to this episode, you'll understand:

What Customer Jobs (Jobs to be Done) are

How to use JTBD to create better solutions for your customers

Why using JTBD helps you to innovate and get better results


Show Notes

Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love.

One of the core concepts behind Customer Jobs (Jobs to be Done) is that competition is defined in the mind of the customer. To put it another way, the market itself is what defines competition.

The Customer Needs Paradigm

Instead of traditional thinking by Product Owners, Analysts, Innovators, and others where we have a narrow view of what our products are, JTBD helps to expand our view. We usually focus on customer needs.

In reality, customers think in terms of the transformation they want; the “new me”. Humans want to evolve. The idea of self-betterment drives us to buy and use new products.

If we can better understand the job they need to be fulfilled (their Job to be Done), we can innovate and develop products will buy and use. We can also use those insights to change our strategies to retain existing customers and find new ones.

Here’s JTBD in action. Increasing milkshake sales using Jobs to be Done

Listen to the full episode to usderstand how to use JTBD to innovate and create products will love.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA120.mp3
Z
Your Homework

Talk to customers who no longer use your product to find out why they left. Do this even for internal customers who aren’t using solutions you’ve developed for them. The insights you gain can lead to changes that benefit others (or bring back lost customers).

Links mentioned in this episode:

When Coffee and Kale Compete

Alan’s JTBD website

Alan Klement

Principal at Customer Jobs Lab

Alan Klement helps teams and individuals become great at making and selling products that people will buy. His own experience as a successful innovator and entrepreneur is what makes him effective at helping others. Alan is also the author of When Coffee and Kale Compete, a book about how using Jobs to be Done (Customer Jobs) can lead to better products and innovation.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA120: Jobs to be Done Theory appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA120: Jobs to be Done Theory Apr 18, 2017
Show notes

In this episode, Alan Klement shows us how Jobs to be Done can help you design better products and spur innovation. Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love.

After listening to this episode, you'll understand:

What Customer Jobs (Jobs to be Done) are

How to use JTBD to create better solutions for your customers

Why using JTBD helps you to innovate and get better results


Show Notes

Jobs to be Done (JTBD) is a mixture of design thinking, lean startup, and agile to help you make great products that people will love.

One of the core concepts behind Customer Jobs (Jobs to be Done) is that competition is defined in the mind of the customer. To put it another way, the market itself is what defines competition.

The Customer Needs Paradigm

Instead of traditional thinking by Product Owners, Analysts, Innovators, and others where we have a narrow view of what our products are, JTBD helps to expand our view. We usually focus on customer needs.

In reality, customers think in terms of the transformation they want; the “new me”. Humans want to evolve. The idea of self-betterment drives us to buy and use new products.

If we can better understand the job they need to be fulfilled (their Job to be Done), we can innovate and develop products will buy and use. We can also use those insights to change our strategies to retain existing customers and find new ones.

Here’s JTBD in action. Increasing milkshake sales using Jobs to be Done

Listen to the full episode to usderstand how to use JTBD to innovate and create products will love.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA120.mp3
Z
Your Homework

Talk to customers who no longer use your product to find out why they left. Do this even for internal customers who aren’t using solutions you’ve developed for them. The insights you gain can lead to changes that benefit others (or bring back lost customers).

Links mentioned in this episode:

When Coffee and Kale Compete

Alan’s JTBD website

Alan Klement

Principal at Customer Jobs Lab

Alan Klement helps teams and individuals become great at making and selling products that people will buy. His own experience as a successful innovator and entrepreneur is what makes him effective at helping others. Alan is also the author of When Coffee and Kale Compete, a book about how using Jobs to be Done (Customer Jobs) can lead to better products and innovation.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA120: Jobs to be Done Theory appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA119: What’s in Your Backlog? Apr 11, 2017
Show notes

In this episode, we discuss the different types of items that may make up a product backlog. Hint: It’s more than just User Stories.

After listening to this episode, you'll understand:

The difference between a Product Backlog and a Sprint Backlog

How to differentiate between Epics, Features, and Stories

The components of a good User Story

What the other types of backlog items are


Show Notes

I often see teams struggle with backlogs and managing the items within their Product Backlogs. There’s more than just User Stories in backlogs too. There could be Epics, Features, Technical Stories, Spikes, and Job Stories to name a few.

What’s the difference between Epics, Features, and Stories? Size. Epics and Features are really just really big User Stories.

Features are User Stories that are too big to fit into a Sprint. They should provide value from the customer perspective and describe the problem or need instead of the solution. Ideally, features should include acceptance criteria formed through a conversation.

User Stories are thin slices of value described from the customer’s perspective. Stories should include acceptance criteria developed by the team through a conversation.

The Three Cs of a User Story

Card – Stories should be brief and should not contain all of the detail. Stories are a reminder of a conversation that will include discussion of the details.

Conversation – More important than the template of a story is the conversation. Every team member should understand the story through a dialogue and be able to discuss details that may change the original story or acceptance criteria (if any is written prior to the conversation). Keeping stories small and without a lot of detail will lead to a richer, more meaningful conversation. Larger, more detailed artifacts lead to assumptions and a lack of a conversation.

Confirmation – The story should include conditions of satisfaction to know the scope of the story and understand when the story is done. The acceptance criteria for a story could be refined into Gherkin format.

Beyond User Stories

System User Story: A strong preference should be placed on creating user-centric stories. However, some teams may work on development that does not interact with end users. In these cases, the role of the user can be a system or device.

Technical Stories: If a team needs to develop functionality needed to implement a number of other user stories or otherwise support the system, their story might not directly impact the end user. Examples include stories focused on non-functional support of the system, stories that address technical debt, or stores focusing on performing architectural work.

These stories may use technical rather than user-centric language. The story should still express the ‘why’ (so that . . .) to ensure the motivation of the story is understood. Technical stories can be used when the scope of the work is contained within a single component/platform and there is no obvious external user or system consuming/benefiting from the result of the story.

The format may be something similar to “Implement ____________ so that __________.”

Other Types of Stories

Spikes: A quick and dirty implementation designed to be thrown away and used to gain knowledge. A common indicator that a spike should be used is when the team is unable to estimate a user story effectively. An effective approach is to word spikes as a question to be answered or an assumption to be validated so that you know whether or not you accomplished the goal of the spike. A spike can be written as “In order to <achieve some goal> <a system or persona> needs to <some action>” or other formats. Spikes should be timeboxed and include acceptance criteria where possible.

Research: Broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate. This is often used when teams don’t know a potential solution. An effective approach is to word research as a question to be answered or an assumption to be validated. Research stories should be timeboxed and/or include conditions to be satisfied (when are you done?).

Tracer Bullets: A very narrow implementation in production quality of an epic or large user story. Tracer bullets are often used when the user story is too large in estimation.

Listen to the full episode to understand the different types of backlog items and how to use them.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA119.mp3

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA119: What’s in Your Backlog? appeared first on Mastering Business Analysis.

Listen on Google Play Music — MBA119: What’s in Your Backlog? Apr 11, 2017
Show notes

In this episode, we discuss the different types of items that may make up a product backlog. Hint: It’s more than just User Stories.

After listening to this episode, you'll understand:

The difference between a Product Backlog and a Sprint Backlog

How to differentiate between Epics, Features, and Stories

The components of a good User Story

What the other types of backlog items are


Show Notes

I often see teams struggle with backlogs and managing the items within their Product Backlogs. There’s more than just User Stories in backlogs too. There could be Epics, Features, Technical Stories, Spikes, and Job Stories to name a few.

What’s the difference between Epics, Features, and Stories? Size. Epics and Features are really just really big User Stories.

Features are User Stories that are too big to fit into a Sprint. They should provide value from the customer perspective and describe the problem or need instead of the solution. Ideally, features should include acceptance criteria formed through a conversation.

User Stories are thin slices of value described from the customer’s perspective. Stories should include acceptance criteria developed by the team through a conversation.

The Three Cs of a User Story

Card – Stories should be brief and should not contain all of the detail. Stories are a reminder of a conversation that will include discussion of the details.

Conversation – More important than the template of a story is the conversation. Every team member should understand the story through a dialogue and be able to discuss details that may change the original story or acceptance criteria (if any is written prior to the conversation). Keeping stories small and without a lot of detail will lead to a richer, more meaningful conversation. Larger, more detailed artifacts lead to assumptions and a lack of a conversation.

Confirmation – The story should include conditions of satisfaction to know the scope of the story and understand when the story is done. The acceptance criteria for a story could be refined into Gherkin format.

Beyond User Stories

System User Story: A strong preference should be placed on creating user-centric stories. However, some teams may work on development that does not interact with end users. In these cases, the role of the user can be a system or device.

Technical Stories: If a team needs to develop functionality needed to implement a number of other user stories or otherwise support the system, their story might not directly impact the end user. Examples include stories focused on non-functional support of the system, stories that address technical debt, or stores focusing on performing architectural work.

These stories may use technical rather than user-centric language. The story should still express the ‘why’ (so that . . .) to ensure the motivation of the story is understood. Technical stories can be used when the scope of the work is contained within a single component/platform and there is no obvious external user or system consuming/benefiting from the result of the story.

The format may be something similar to “Implement ____________ so that __________.”

Other Types of Stories

Spikes: A quick and dirty implementation designed to be thrown away and used to gain knowledge. A common indicator that a spike should be used is when the team is unable to estimate a user story effectively. An effective approach is to word spikes as a question to be answered or an assumption to be validated so that you know whether or not you accomplished the goal of the spike. A spike can be written as “In order to <achieve some goal> <a system or persona> needs to <some action>” or other formats. Spikes should be timeboxed and include acceptance criteria where possible.

Research: Broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate. This is often used when teams don’t know a potential solution. An effective approach is to word research as a question to be answered or an assumption to be validated. Research stories should be timeboxed and/or include conditions to be satisfied (when are you done?).

Tracer Bullets: A very narrow implementation in production quality of an epic or large user story. Tracer bullets are often used when the user story is too large in estimation.

Listen to the full episode to understand the different types of backlog items and how to use them.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA119.mp3

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA119: What’s in Your Backlog? appeared first on Mastering Business Analysis.

Penny Pullan's Virtual Leadership Model — MBA118: Virtual Leadership Apr 04, 2017
Show notes

In this episode, Dr. Penny Pullan shares strategies for working on virtual project teams and helps us get the most out of virtual work.

After listening to this episode, you'll understand:

The challenges virtual project teams face

How we’re all leaders and need to work with teams

Why starting with yourself leads to better work for virtual teams

How to overcome challenges such as language barriers and time zone differences


Show Notes

The best form of communication is face-to-face with a whiteboard or another visual tool. However, the reality is that many teams aren’t co-located. Virtual teams can have many challenges including culture difference, language barriers, time zones, and simply a lack of engagement and difficulty creating a shared understanding.

The Virtual Leadership Approach

Virtual leadership is applicable for any team of people who want to get things done together and at least one person is remote from the others. Many traditional leadership approaches don’t work well with virtual teams; a different approach is needed.

The concept of virtual leadership goes beyond people management. It’s an approach for working together and getting things done on a virtual team regardless of your role.

We all need to get things done with and through other people. This approach is about working together to build a shared vision and leadership among the entire team. The goal is to develop a team that can share and flex leadership depending on the specific task or situation.

Get Engagement

Whether your remote team member is on another floor or across the planet, one of the most common problems is the lack of engagement. On conference calls, people fail to focus on the conversation or multitask instead of engaging with others.

Failing to call out and address this behavior only leads to more such behavior.

To address this problem, start by setting team norms. This can be done when first forming the team and even at the start of each meeting.

Norms can include agreeing on ways the team communicates. You may decide that as part of the meeting, you’ll do a quick round of polling every 10-15 minutes (or random intervals) by asking each person for input and having them say a word or two to ensure engagement and focus on the goal of the meeting.

Be a Better Virtual Leader

At the core of virtual leadership is the self. You need to know yourself; your strengths, weaknesses, and preferences. This allows you to understand your current skills and where you need to grow (e.g., organizational skills and technology) to get better at virtual leadership.

The next stage is looking at working with others and how they work with you. To be successful, you need to understand the people you’re working with along with their skills, preferences, and mindset.

Outside of knowing yourself and others, you’ll need to know how to use the technology that enables virtual communication. You’ll also need to be able to work within meetings and between meetings.

After you’ve sharpened those skills, you can begin to deal with the challenges of virtual teams such as time zone differences, language barriers, cultural differences, generational differences, and other issues.

Penny’s Virtual Leadership Model

To be an authentic virtual leader, start with yourself. Be present, work to build trust, and plan appropriately to engage virtual team members.

Listen to the full episode to understand how to be an effective virtual leader and overcome some of the challenges associated with virtual teams.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA118.mp3
Z
Your Homework

Prepare for virtual meetings by understanding yourself and others and build your skills to be effective in a virtual environment. During meetings, be present and engage with others.

At the end of your virtual meeting, spend a few minutes to get input from the team as to what went well during the meeting and what can be improved. Then take action and discuss progress at the beginning of the next meeting.

Links mentioned in this episode:

Penny’s website MakingProjectsWork.co.uk

The BA Summit

Penny’s book Virtual Leadership (Use code VLF20 for 20% discount)
Use code VLF20 for 20% discount

Dr. Penny Pullan

Dr. Penny Pullan is a consultant, mentor, speaker and author. Penny works with people in multinational organizations who are struggling with complex projects; those with ambiguous requirements, disengaged stakeholders, and geographically disbursed teams. Her latest book is Virtual Leadership: Practical Strategies for Getting the Most Out of Virtual Teams and Virtual Work. Penny also runs an annual virtual conference for Business Analysts.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA118: Virtual Leadership appeared first on Mastering Business Analysis.

Penny Pullan's book, Virtual Leadership — MBA118: Virtual Leadership Apr 04, 2017
Show notes

In this episode, Dr. Penny Pullan shares strategies for working on virtual project teams and helps us get the most out of virtual work.

After listening to this episode, you'll understand:

The challenges virtual project teams face

How we’re all leaders and need to work with teams

Why starting with yourself leads to better work for virtual teams

How to overcome challenges such as language barriers and time zone differences


Show Notes

The best form of communication is face-to-face with a whiteboard or another visual tool. However, the reality is that many teams aren’t co-located. Virtual teams can have many challenges including culture difference, language barriers, time zones, and simply a lack of engagement and difficulty creating a shared understanding.

The Virtual Leadership Approach

Virtual leadership is applicable for any team of people who want to get things done together and at least one person is remote from the others. Many traditional leadership approaches don’t work well with virtual teams; a different approach is needed.

The concept of virtual leadership goes beyond people management. It’s an approach for working together and getting things done on a virtual team regardless of your role.

We all need to get things done with and through other people. This approach is about working together to build a shared vision and leadership among the entire team. The goal is to develop a team that can share and flex leadership depending on the specific task or situation.

Get Engagement

Whether your remote team member is on another floor or across the planet, one of the most common problems is the lack of engagement. On conference calls, people fail to focus on the conversation or multitask instead of engaging with others.

Failing to call out and address this behavior only leads to more such behavior.

To address this problem, start by setting team norms. This can be done when first forming the team and even at the start of each meeting.

Norms can include agreeing on ways the team communicates. You may decide that as part of the meeting, you’ll do a quick round of polling every 10-15 minutes (or random intervals) by asking each person for input and having them say a word or two to ensure engagement and focus on the goal of the meeting.

Be a Better Virtual Leader

At the core of virtual leadership is the self. You need to know yourself; your strengths, weaknesses, and preferences. This allows you to understand your current skills and where you need to grow (e.g., organizational skills and technology) to get better at virtual leadership.

The next stage is looking at working with others and how they work with you. To be successful, you need to understand the people you’re working with along with their skills, preferences, and mindset.

Outside of knowing yourself and others, you’ll need to know how to use the technology that enables virtual communication. You’ll also need to be able to work within meetings and between meetings.

After you’ve sharpened those skills, you can begin to deal with the challenges of virtual teams such as time zone differences, language barriers, cultural differences, generational differences, and other issues.

Penny’s Virtual Leadership Model

To be an authentic virtual leader, start with yourself. Be present, work to build trust, and plan appropriately to engage virtual team members.

Listen to the full episode to understand how to be an effective virtual leader and overcome some of the challenges associated with virtual teams.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA118.mp3
Z
Your Homework

Prepare for virtual meetings by understanding yourself and others and build your skills to be effective in a virtual environment. During meetings, be present and engage with others.

At the end of your virtual meeting, spend a few minutes to get input from the team as to what went well during the meeting and what can be improved. Then take action and discuss progress at the beginning of the next meeting.

Links mentioned in this episode:

Penny’s website MakingProjectsWork.co.uk

The BA Summit

Penny’s book Virtual Leadership (Use code VLF20 for 20% discount)
Use code VLF20 for 20% discount

Dr. Penny Pullan

Dr. Penny Pullan is a consultant, mentor, speaker and author. Penny works with people in multinational organizations who are struggling with complex projects; those with ambiguous requirements, disengaged stakeholders, and geographically disbursed teams. Her latest book is Virtual Leadership: Practical Strategies for Getting the Most Out of Virtual Teams and Virtual Work. Penny also runs an annual virtual conference for Business Analysts.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA118: Virtual Leadership appeared first on Mastering Business Analysis.

Jared Wiese — MBA117: Getting Requirements Right Mar 28, 2017
Show notes

In this episode, Jared Wiese shares an approach for focusing on value to help you not just elicit requirements, but to get requirements right.

After listening to this episode, you'll understand:

How to decompose requirements into smaller, valuable chunks

Why simply asking customers questions about what they want is the wrong approach

How to map value using the BML approach

The three magic words to help you focus on delivering value


Show Notes

As project professionals, we often help clearly articulate the requirements to develop and deliver a solution. However, getting requirements right can be challenging.

Sometimes the requirements don’t address what the customer truly needs. Your requirements may be exactly what the customer asked for yet not solve the real problem.

Getting requirements right helps us to solve the right problem with the right solution while focusing on real value.

The Challenge with Getting Requirements Right

There’s frequently a misconception that we need to come to a requirements elicitation meeting with exactly the right questions to ask. That approach actually slows things down and prevents you from finding the true need.

Asking too many questions and being forced into a checklist of questions can derail the conversation from leading to a better understanding of the context and the underlying business problem to be solved.

Instead, start with a better question; What is the real business objective or goal we’re trying to achieve?

In Order To . . .

Starting with the goal (the big ‘Why’) allows you to drill down and understand the context and the scope of what you’re trying to achieve.

Asking why an initiative is important to get to the ‘in order to’ statement helps you decompose a problem further and discover the right questions to ask. It allows you to drive out the value and focus on the right things.

Business Modeling Language

Using Business Modeling Language (BML) or a similar approach such as story mapping, you can visually decompose larger items into more detail and discover the full scope.

BML helps you model the business process or unction and discover what it takes to achieve the goal.

Asking “In order to do X, what do we need to do?” allows you to flesh out the details of the project and focus only on that which gets you closer to the overall goal.

By collaborating together and focusing on the ‘Why”, you can better manage scope, focus on value, and deliver better business outcomes.

Listen to the full episode to hear all of Jared’s advice on how to get requirements right.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA117.mp3
Z
Your Homework

Try using the “in order to” clause to gain clarity, decompose requirements, and focus on value.

Links mentioned in this episode:

Jared’s article: How to Get Business Analysis Requirements Right

Jared Wiese

IT Business Analyst | Career Coach

Jared Wiese is an IT Business Analyst, Career Coach, and Life Strategist. His passion is improvement and he looks for ways to simplify and improve life for others. Jared is speaker and an active contributer to the Business Analysis community through his LinkedIn articles.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA117: Getting Requirements Right appeared first on Mastering Business Analysis.

Subscribe on iTunes — MBA117: Getting Requirements Right Mar 28, 2017
Show notes

In this episode, Jared Wiese shares an approach for focusing on value to help you not just elicit requirements, but to get requirements right.

After listening to this episode, you'll understand:

How to decompose requirements into smaller, valuable chunks

Why simply asking customers questions about what they want is the wrong approach

How to map value using the BML approach

The three magic words to help you focus on delivering value


Show Notes

As project professionals, we often help clearly articulate the requirements to develop and deliver a solution. However, getting requirements right can be challenging.

Sometimes the requirements don’t address what the customer truly needs. Your requirements may be exactly what the customer asked for yet not solve the real problem.

Getting requirements right helps us to solve the right problem with the right solution while focusing on real value.

The Challenge with Getting Requirements Right

There’s frequently a misconception that we need to come to a requirements elicitation meeting with exactly the right questions to ask. That approach actually slows things down and prevents you from finding the true need.

Asking too many questions and being forced into a checklist of questions can derail the conversation from leading to a better understanding of the context and the underlying business problem to be solved.

Instead, start with a better question; What is the real business objective or goal we’re trying to achieve?

In Order To . . .

Starting with the goal (the big ‘Why’) allows you to drill down and understand the context and the scope of what you’re trying to achieve.

Asking why an initiative is important to get to the ‘in order to’ statement helps you decompose a problem further and discover the right questions to ask. It allows you to drive out the value and focus on the right things.

Business Modeling Language

Using Business Modeling Language (BML) or a similar approach such as story mapping, you can visually decompose larger items into more detail and discover the full scope.

BML helps you model the business process or unction and discover what it takes to achieve the goal.

Asking “In order to do X, what do we need to do?” allows you to flesh out the details of the project and focus only on that which gets you closer to the overall goal.

By collaborating together and focusing on the ‘Why”, you can better manage scope, focus on value, and deliver better business outcomes.

Listen to the full episode to hear all of Jared’s advice on how to get requirements right.

http://traffic.libsyn.com/masteringbusinessanalysis/MBA117.mp3
Z
Your Homework

Try using the “in order to” clause to gain clarity, decompose requirements, and focus on value.

Links mentioned in this episode:

Jared’s article: How to Get Business Analysis Requirements Right

Jared Wiese

IT Business Analyst | Career Coach

Jared Wiese is an IT Business Analyst, Career Coach, and Life Strategist. His passion is improvement and he looks for ways to simplify and improve life for others. Jared is speaker and an active contributer to the Business Analysis community through his LinkedIn articles.

X
LinkedIn

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

.

The post MBA117: Getting Requirements Right appeared first on Mastering Business Analysis.

Previous 1 14 15 16 17 18 28 Next

Related Podcasts

Making Sense with Sam Harris — 1
Making Sense with Sam Harris Education

Grammar Girl — 2
Grammar Girl Education

Good Life Project — 3
Good Life Project Education

Explain It to Me — 4
Explain It to Me Education

Team Never Quit — 5
Team Never Quit Comedy

Optimal Living Daily – Personal Development and Self-Improvement — 6
Optimal Living Daily – Personal Development and Self-Improvement Alternative Health

Contact Us

Toll Free: 844-670-7747

Links

Home
Top Charts
Networks
Apps
Independents Podcasts

Podcast Advertising
Podcast News
Contact Us
About Us
Analytics & Insights

Stay Connected

Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights