TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Education

    Mastering Business Analysis

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

    Advertise

    Copyright: © MasterClass 247 LLC

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    MBA106: Rapid Requirements Gathering Jan 10, 2017
    Show notes

    In this episode, Scott Killen tells us how to quickly elicit requirements from a large, diverse group of people with very little preparation using an approach he calls a Rapid Requirements Gathering meeting.

    

    After listening to this episode, you'll understand:

    • Why Rapid Requirements Gathering (RRG) meetings are so powerful
    • How to facilitate an RRG meeting
    • The pros and cons of using an RRG meeting
    • How to get started using this approach for yourself
    

    Show Notes

    Want to quickly elicit requirements from a large, diverse group of people with very little preparation? A Rapid Requirements Gathering meeting can help you do just that. It’s a mixture of high level rigid structure, organized chaos, and some fun.

    The Rapid Requirements Gathering meeting is structured as a set of ten time-boxed activities. Each activity is highly interactive and collaborative, leading to great outcomes.

    As a result, you’ll be able to quickly develop a categorized, prioritized, and actionable list of requirements from a group of 10 to 75 stakeholders.

    You’ll need a room with smooth walls, a few different colors of 3×5 yellow sticky notes, sharpie markers, and a rubber band.

    The activities during the Rapid Requirements Gathering meeting are:

    Introduction and review: Introduce all participants and review the meeting goal. It’s helpful to explain the meeting format and give examples of requirements to demonstrate the kind of information you hope to get from the meeting.

    Enumerate items: Attendees silently brainstorm requirements for a fixed period of time using the sticky notes and sharpie markers.

    Review items: After randomizing the sticky notes from each attendee to preserve anonymity, read each requirement out loud and stick it on the wall. As you read each requirement, new requirements may come up and should be added.

    Associate items: Attendees group like requirements together into affinity groups. If new items are identified, they can be added.

    Categorize items: Create a meaningful label or title for each affinity group.

    Rationalize items: Combine or remove duplicate requirements and add, rewrite, or re-categorize individual requirements as needed.

    Prioritize items by category: Teams of attendees collaborate to rank order the requirements in each affinity group.

    Discuss results: Discuss the highest priority items for additional detail and clarity.

    Rank overall importance: Use dot voting to identify highest priority requirements across all categories.

    Final Review: Summarize the meeting results and discuss next steps. You will likely need to follow up with stakeholders to get more detail on some items.

    After the meeting, collect all of the sticky notes for later use.

    Listen to the full episode to understand how to facilitate a rapid Requirements Gathering meeting, hear the pros and cons of using this approach, and to find out what to do with the rubber band.

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

    Z

    Your Homework

    Try using a Rapid Requirements Gathering meeting with a small group of people using Scott’s instructions (see links below). It’s much easier to start with a small group to gain confidence with using RRG meetings.

    Links mentioned in this episode:

    • Rapid Requirements Gathering Meeting Facilitation Guide
    Scott Killen

    Scott Killen

    Agile Practice Leader at Paypal

    Scott Killen is a founder and previous President of Agile Austin as well as the Agile Practice Leader for PayPal. He is a Certified Scrum Master and Certified Scrum Practitioner through the Scrum Alliance. He’s a Certified Project Management Professional (PMP) and a Certified SAFe consultant. Scott also instructed IT Project Management and Agile Project Leadership at Austin Community College.

    • 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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA106: Rapid Requirements Gathering appeared first on Mastering Business Analysis.


    MBA105: The Best Advice I Ever Received Jan 03, 2017
    Show notes

    In this episode, ten thought leaders in the field if business analysis and project management share the best advice they ever received.

    Happy New Year!

    To start the year off right, I’ve brought together some of the top leaders in the world of business analysis to share the best advice they ever received.

    Kupe Kupersmith

    Kupe Kupersmith | President, B2T Training

    Be comfortable with who you are and be who you are. You can look at other people to see if there are qualities you want to take on but you’re never going to be that other person you are who you are just be you.

    Richard Larson

    Richard Larson | Founder and President of Watermark Learning

    Do what you love and what you’re good at and success will follow.

    Elizabeth Larson

    Elizabeth Larson | CEO of Watermark Learning

    Whenever possible, spend time in your stakeholder’s area using their systems and doing what they do. This not only helps build trust, it also gives you the knowledge to identify problems and make solution recommendations.

    David Mantica

    David Mantica | President, ASPE-Training

    David shared two pieces of advice that he received at different points in his career.

    1. You’re going things at work that you want to do and things that you don’t want to do. Focus on the things you don’t want to do and complete those first. They are usually the most important.
    2. You’re a leader. People watch you. Be cognizant of that.

    Roxanne Miller

    Roxanne Miller | President, Requirements Quest

    Get some good books, read them, and apply the lessons from those books (Roxanne recommends Software Requirements by Karl Weigers). Also, get a mentor.

    Paula Bell

    Paula Bell | Paula A. Bell Consulting, LLC

    Be true to yourself and be authentic. Don’t let your circumstances define who you are rather overcome them to define where you’re going.

    Cheryl Lee

    Cheryl Lee | Co-author of the book Effective PM and BA Role Collaboration

    You can talk to people about the value you provide to the organization, but the best way you can prove your value is to show them.

    Hans Eckman

    Hans Eckman | Eckman Guides

    An ecosystem is greater than the sum of its parts. Take a step back and look at the organization holistically to see if there are larger patterns or influences we need to take into account for our solution.

    Adrian Reed

    Adrian Reed | Principal Consultant at Blackmetric Business Solutions

    Adrian shared three pieces of advice he received:

    1. Embrace uncertainty. It’s okay not to know yet.
    2. Network
    3. Be authentic and be yourself.

    Angela Wick

    Angela Wick | Founder and CEO of BA-Squared, LLC

    Your job is to add value every single day. Ask yourself three questions:

    1. At the beginning of the day ask “how will I add value today?”
    2. In the middle of the day ask “How am I adding value by doing this?”
    3. At the end of the day ask “Did I add value today?”

    I hope you’ve found something in this advice that can help you in 2017. Of course, it will only have an impact if you take action. Make 2017 your year.

    Listen to the full episode to hear the best advice these ten thought leaders ever received (as well as my own).

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA105.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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA105: The Best Advice I Ever Received appeared first on Mastering Business Analysis.


    MBA104: Predictions for 2017 Dec 27, 2016
    Show notes

    In this episode, I’ll share my predictions for 2017 and what they mean to you.

    Based on what’s been happening in the industry, I’ve peered into my crystal ball and have four predictions that will impact Business Analysts, Project Managers, and other project professionals.

    There are four industry trends that will shape your role in 2017. Those trends are:

    1. Technology shifts
    2. The focus on products over projects
    3. The continued use of Agile & lean
    4. The evolving role of the Business Analyst

    Prediction #1: Technology Changes Will Shape Your Role

    There will be a greater push toward machine learning, the cloud, and DevOps. You’ll need to understand at least at a high level what these tools and associated practices are in order to be able to advise your organization on potential solutions.

    The other technology trend for 2017 is the Internet of Things (IoT). What this really means is that devices will have more sensors which provide more data. That leads us to greater usage of big data tools and practices.

    Project professional who understand big data concepts and can mine data for business insights will be in high demand.

    Prediction #2: There Will Be a Shift from Projects to Products

    The shift in focus toward products is really a focus on value. Businesses need better results from investments and they’ll need project professionals who can lead them to better business outcomes.

    This is more than just selecting the right projects. It’s focusing on features and capabilities that will be valuable to customers in a continuous flow and adapting along the way.

    This means less project requirements in favor of features and capabilities with requirements evolving over time. The approach of big design upfront (creating all requirements in the beginning) will be used less and we’ll deliver in smaller phases or increments, adapting along the way based on customer feedback.

    With the focus on products, the skill (and role) of Product Management will be in greater demand.

    Prediction #3: There Will Be a Continued Push Toward Agile and Lean Practices

    Organizations that have not yet adopted Agile and lean practices will begin experimenting with those practices. That’s because there is more pressure in the market to “be agile” and provide what customers perceive as faster and better delivery.

    Many organizations will continue to struggle with Agile implementations and will adopt a hybrid approach in 2017. Some that say they are fully Agile will be agile in name only, adopting some of the practices without the needed shift in mindset.

    With this shift, project professionals will need to adopt light-weight practices and create less documentation. The focus will be on outcomes over outputs.

    As a result, highly collaborative approaches such as visual modeling and user stories will be used to reduce documentation.

    Many organizations will also struggle to understand where the BA fits in an Agile environment. Through that challenge, I think we’ll see the real value of the Business Analyst; value managers.

    Organizations will also struggle with colocation versus a geographically diverse workforce. As a result, companies will adopt more tools for virtual collaboration. People who understand how to make the best use of those tools will be better off.

    Prediction #4: The BA Role Will Evolve

    Because of the trends mentioned earlier, technology shifts, focusing on products, and the emphasis on Agile, the Business Analyst role will evolve in 2017.

    While business analysis will be wildly popular in 2017, we’ll see less roles with the title of “Business Analyst”. There will be more combined Project Manager/Business Analyst roles in 2017 as organizations struggle to figure out where both roles fit in Agile.

    More BAs will move into Product Owner or Project Manager roles and new specialized roles will emerge. To be successful, Business Analysts will need to focus on value and look at initiatives through three lenses of business value, technical feasibility, and user experience.

    The shift in focus also means that there will be an increase in the use of Design Thinking and Lean Startup approaches.

    With much of the evolution in the BA role, practitioners who want to be successful will need to focus their training and development of soft skills. Facilitation, communication, collaboration, and the ability to influence will be critical.

    The biggest soft skill area that I see in 2017 is emotional intelligence (EI or EQ). This is the ability to understand your own emotions and those of others to adapt your behaviors. A higher EQ leads to better relationships and a greater ability to influence and collaborate.

    Listen to the full episode to hear the full details of these four predictions including what will happen to the BA role with the emergence of new certifications.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA104.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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA104: Predictions for 2017 appeared first on Mastering Business Analysis.


    MBA103: How Mr. Finch Stole the Project Dec 20, 2016
    Show notes

    Happy holidays! In this episode, we hear the tale of Mr. Finch as he tries to sabotage the project, read in the style of the popular children’s author, Dr. Seuss.

    Every stakeholder at Acme liked the project a lot . . .

    But Mr. Finch, who was from Finance, did not

    Mr. Finch hated projects; he thought they were all messes

    No one knows why for sure, but I have a few guesses

    It could be the impact they had on his group.

    His system was complex; people left him out of the loop.

    But probably the most likely reason of all,

    Was that his vision was just a little too small.

    Benefiting his department was Finch’s singular goal.

    He didn’t consider the value to Acme as a whole.

    Whatever the reason, as the project progressed,

    Mr. Finch was planning something no one would have guessed.

    For next week, old Finch knew, would be implementation.

    And that scared Mr. Finch; experienced in this situation.

    It would arrive with cheering and all would look great.

    Until complaints start coming and the reports will be late.

    First would come emails; asking for more data

    Then the errors and bugs will start coming; it won’t be tested in beta.

    “My precious ledger will be broken!” Finch said shaking his fist.

    “No one understands; my needs will be missed.”

    Then delays and more changes; always such a mess.

    Working late hours, more gray hair from the stress.

    The more Finch thought, the more he began to worry.

    He must put a stop to the project, and do it in a hurry.

    “Why, I’ve been at Acme for 15 years now.”

    “I must stop this project from coming! But how?”

    As he schemed and plotted during that day’s JAD session,

    He saw the BA and thought “Ah . . . I’ll teach him a lesson!”

    He would meet with the BA, in the spirit of cooperation.

    Any then destroy the documents – the output of elicitation.

    For without the documents, the project will surely fail.

    With no changes to his process, Mr. Finch would prevail!

    Clearing his throat, Mr. Finch asked for a meeting.

    And later in his office, met the BA with a warm smile and greeting.

    As the two discussed the project, the BA asked some great questions.

    They drew on the whiteboard, Mr. Finch even offered suggestions.

    “What harm could it do?” thought old Finch with a sneer.

    The documents will go missing; I won’t shed a tear.

    Without requirements and specs, no one will know what to do.

    The project will be lost; no one has a clue.

    That very night old Finch put his plan into action.

    Deleting files from the repository while laughing with satisfaction.

    Away to find hard copies he flew like a flash.

    He shredded them all and emptied the trash.

    That old Finch was so cunning and mean,

    To ensure there was no trace, he even wiped the whiteboards clean.

    He hid Post-Its and markers to each cabinet he flew.

    He locked them all away – a place only Finch knew.

    From hard drives and thumb drives to notebooks and ink,

    Finch removed all project records, then went out for a drink.

    As he sat in the bar, sipping his cold ale,

    He laughed to himself; for he’d made the project fail.

    “When launch day comes, there will be no more cheering.”

    “No more changes – what I had most been fearing.”

    “I’ll stop every project from this moment on.”

    “Documents are the key, and the BA’s just a pawn.”

    “He writes the documents that tell others what to do.”

    “A note taker, really; he doesn’t have a clue.”

    That night as Mr. Finch placed pillow to head,

    He chuckled once more, for he had nothing to dread.

    He dreamed wonderful, awful dreams of a place without change.

    Nothing unfamiliar, awkward, or strange.

    As the planned implementation date drew ever near,

    Old Finch whistled happily; he had nothing to fear.

    When project launch day had finally arrived,

    Finch pretended to be concerned, an emotion contrived.

    He arrived in the office will before dawn,

    So he could witness the mayhem his plotting had spawn.

    As time counted down with each single tick,

    He grew confident in his plan, no more changes will stick.

    “Too bad for the BA!” Finch was happily humming.

    “I’ve finally done it – stopped the project from coming!”

    The sponsor is likely discovering now,

    That his project has failed and the BA disavow.

    I’ll hear yelling and questions and strong accusation.

    Future projects will be questioned – it’ll be a vacation.

    He thought to himself, “That will be something to hear.”

    So he tilted his head and put his hand to his ear.

    And he did hear a sound coming down the hall.

    But it wasn’t quite what Finch expected at all.

    It was the sound of cheering and dashboards were green.

    Finch sat there puzzling, “What could it all mean?”

    “It came without a BRD! It came without specs!”

    “It came without documents, bugs, and stress!”

    His own team was cheering, and laughing with smiles.

    They came toward old Finch, crossing the aisles.

    “The project went in, our jobs have been saved!”

    This was most unexpected, Finch confused by the way they behaved.

    So Finch pondered the project and what they could mean.

    What is this project, to create such a scene?

    He pondered and wondered until his cranium was sore.

    Then Finch considered something he hadn’t considered before.

    Perhaps a shared understanding isn’t on paper at all.

    Perhaps collaboration and working together helped us answer the call.

    And what happened then? Well at Acme they say,

    Finch finally saw the big picture that day.

    He understood the impact of the project, without abstraction.

    Increased revenue, market share, and customer satisfaction.

    Without innovation and change, we will never evolve.

    Acme wouldn’t keep up, we would surely dissolve.

    By working together, co-creating a shared vision,

    We all know what to do and can make a decision.

    And the moment he understood the importance of change,

    Mr. Finch didn’t feel quite so strange.

    Finch quickly got up and with no delay,

    Finch extended his hand, and thanked the BA.

    Listen to the full episode here.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA103.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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA103: How Mr. Finch Stole the Project appeared first on Mastering Business Analysis.


    MBA102: Product Management – Build the Right Thing Dec 13, 2016
    Show notes

    In this episode, Rich Mironov will help us to better understand the role of Product Manager, how it differs from Product Owner, and what we can do to make sure we build a solution that drives success for our organization.

    

    After listening to this episode, you'll understand:

    • What product management is
    • How a Product Manager differs from Product Owner
    • How you can support product management activities
    

    Show Notes

    A Product Manager is the person who has one foot in the market side and one foot in the engineering side. They make sure we not only build things right, but build the right things that drive success for the company.

    The measure of success for a product manager isn’t that we ship stuff on time, it’s delivering things that drive customer joy, market advancement, and value in the minds of our customers.

    Product Owner vs Product Manager

    PO as defined by Scrum – inward facing portion of product management. Direction is given at a higher level. In essence, Product Owners implement choices, decisions, and strategies that someone else has made by breaking them down at the team level for execution.

    Good Product Owners are focused on goals and value and get out from behind their desks to better understand customers and markets. They’re not just taking direction.

    The challenge is that many products can’t be delivered by just one team. This assumes that the teams are properly structured with the right skills to deliver their portion. It also assumes that the solutions developed by multiple teams will somehow come together for a cohesive, valuable solution.

    Another challenge is that these individual teams often focus on output versus outcomes. Instead of focusing on delivering stories, teams need to focus on delivering positive business outcomes and value.

    Measuring Business Value

    Often, business value is expressed either as a vague guess of future revenue, cost savings, or hours saved. There’s a huge margin of error in these value estimations.

    Additionally, the expression of value in terms of time saved is meaningless unless we understand what can be done with that saved time. If that free time does not translate into a reduction in staff or reduced hiring needs, perhaps the people can now focus on income producing work. Otherwise, there is no real value in the time savings.

    Bringing along a User Experience (UX) designer and engineer to speak with the customer also helps to bring out different perspectives and often results in better outcomes.

    How Can We Help?

    Often, Product Managers give us a solution to implement. Instead, we’d like to get a problem to solve with the full context so that we can find an appropriate solution.

    As project professionals, we can help by walking them a step back to discover the underlying business problem and help them find the appropriate solution out of multiple options.

    “We’ll get better results if as a team we wrestle with the why and what before the how.”

    Creating a collaborative environment with diversity of thought centered on finding the best solution will yield greater results than a single Product Manager telling engineers what solution to build.

    Listen to the full episode to hear all of Rich’s tips and advice for building the right solution.

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

    Z

    Your Homework

    Get out from behind your desk and talk to your customers. Get firsthand information on what their pain points are and identify what would be valuable to them.

    Links mentioned in this episode:

    • Rich’s website Mironov.com
    Rich Mironov

    Rich Mironov

    CEO, Mironov Consulting

    Rich Mironov is an author, speaker, and innovator. Rich coaches product executives, product management teams and agile development organizations. He also parachutes into software companies as interim VP of Products to fix company-level product, market, engineering, and revenue issues. Rich is also the author of The Art of Product Management.

    • 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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA102: Product Management – Build the Right Thing appeared first on Mastering Business Analysis.


    MBA101: Split Your Stories! Dec 06, 2016
    Show notes

    In this episode, Chris Sims shares four techniques to split your user stories to make them smaller, more manageable, and to help draw out details.

    

    After listening to this episode, you'll understand:

    • The problems big user stories can cause
    • How big your user stories should be
    • Why splitting stories helps create a shared understanding
    • How just four splitting techniques apply to almost all stories
    

    Show Notes

    User stories that are too big are a common problem. Big user stories make it difficult for the team to complete the story within the iteration and they often make impediments less visible.

    How big should a user story be? It depends.

    Near-term user stories at the top of your backlog should be small enough to be completed within a day or two. Items further down on your backlog can be larger and less refined.

    The farther out a story is, the bigger it can be because you don’t want to over invest in stories that may change. This is the power of doing just enough just in time.

    To get near-term stories into our state that’s ready for the team to execute upon, the team should meet weekly to review and refine the backlog. This refinement includes splitting stories to make sure they are small enough and adding detail around the acceptance criteria.

    Splitting stories not only creates smaller stories, it also generates more detail about the user story through a conversation of how that story changes when split.

    While there are dozens of ways to split user stories, knowing how to use just a handful of approaches will help you in most situations.

    Chris Sims recommends four approaches to splitting stories:

    • Split by conjunctions and connector words
    • By analyzing generic words
    • Using acceptance criteria
    • Through timeline analysis

    Splitting Conjunctions and Connector Words

    Within the narrative portion of the user story (most commonly the “As a . . . I want . . . So that” portion), look for conjunctions and connector words such as and, or, but, with, etc.

    You can often split the story at those connector words and have two smaller stories. For example, the user story:

    “As an online banking customer, I want to be able to view my account and make updates so that my account has the correct information”

    can be split into

    “As an online banking customer I want to be able to view my account information so that I can verify information is correct”

    and

    “As an online banking customer I want to be able to make updates to my account information to correct any erroneous information”

    Look For Generic Words

    Another way to split user stories is to elaborate on generic words used in the narrative portion. Generic words are terms that are very general and broad.

    You can identify generic words by asking yourself “What kinds of those are there?” Example:

    “As a user of the system, I want to be able to maintain my account details . . . “

    For the above statement we can ask “what different types of users of the system are there?’ There may be users with administrative access, users with regular access, logging users, users who are not logged in, etc.

    You can create a separate user story for each of these user types. This not only makes user story smaller, it also helps you to have a more detailed discussion about the specific needs of a user.

    The word “maintain” is also a generic word. There may be many different actions as part of maintaining an account including updating name, updating e-mail address, updating mailing address, adding upgrades users, and even deleting the account.

    This approach allows you to incrementally build a solution that addresses different needs.

    Use Acceptance Criteria

    Chris’ third way of splitting user stories is by acceptance criteria. Acceptance criteria are the pass fail tests that specify the scope of the story and tell you when it’s done.

    If the user story has four acceptance criteria, teams will often split it by breaking it into identical user stories each with only a few of the acceptance criteria. Chris’ approach is a bit different.

    Chris recommends looking at the acceptance criteria to determine if each criterion can be reformatted into a separate story.

    The acceptance criteria becomes the middle of a user story narrative and then you can identify who would benefit from that story and what their goal would be. That creates a complete, smaller user story.

    Timeline Analysis for Splitting Stories

    The fourth wave splitting user stories is best for capabilities that involve user interaction. The approach is known as timeline analysis or use case analysis.

    With this approach you identify the steps that a user must go through to complete a process associated with the user story. Each step in that process may then become its own user story.

    This approach may allow you to validate and test with users as you deliver small pieces of functionality to ensure the solution meets their needs and make any needed adjustments.

    Listen to the full episode for more examples on how to use these story splitting techniques.

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

    Z

    Your Homework

    Practice the four techniques for story splitting and sample user stories. Practicing these splitting techniques on made up stories allows you to try them out in a no risk environment. You also won’t be distracted by the real-world details within the context of your stories.

    Links mentioned in this episode:

    • Agile Learning Labs
    • SmallerStories.com
    Chris Sims

    Chris Sims

    Founder of Agile Learning Labs

    Chris Sims is a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness. Chris is the founder of Agile Learning Labs and co-author of two best-selling scrum books: The Elements of Scrum and Scrum: a Breathtakingly Brief and Agile Introduction.

    • 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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA101: Split Your Stories! appeared first on Mastering Business Analysis.


    MBA100: My Biggest Mistake Nov 29, 2016
    Show notes

    In this episode, eight thought leaders in the business analysis field share their biggest mistake and what they learned from it.

    “Only a fool learns from his own mistakes. The wise man learns from the mistakes of others.” – Otto Von Bismarck

    The above quote is the idea behind today’s episode. I’ve brought together eight leaders in the world of business analysis to share their biggest mistakes.

    The goal is twofold; first, to help you learn from the mistakes of others so that you don’t make the same mistake and secondly, to help you to realize that most mistakes aren’t fatal – you can make a big mistake and still have a successful career. The key is learning from those mistakes.

    Richard Larson

    Richard Larson | Founder and President of Watermark Learning

    Richard shares the story of how his career was sidetracked from his true calling.

    What Richard learned: Your career is almost never a straight line. It can take many twists and turns. It may even seem like you’re moving in the wrong direction. Just remember that you often pick up new ideas, skills, and knowledge through all those twists that you can apply later in your career.

    Elizabeth Larson

    Elizabeth Larson | CEO of Watermark Learning

    Elizabeth tells us about how failing to follow some good advice limited her effectiveness.

    What Elizabeth learned: You’re more than just a translator or liaison. To be successful, you need to spend time to understand your stakeholders and develop trust and credibility.

    Roxanne Miller

    Roxanne Miller | President, Requirements Quest

    Roxanne tells a story of how a missed requirement led to huge negative consequences for one organization.

    What Roxanne learned: Ask the right questions. Often, we’re given a solution to implement and don’t look outside the parameters we’re given. ‘What if’ can be a powerful way to start a thought provoking conversation. Developing an understanding of your industry and looking at things from the customer’s point of view helps you ask the right questions and address assumptions.

    Cheryl Lee

    Cheryl Lee | Co-author of the book Effective PM and BA Role Collaboration

    Cheryl tells us how having overconfidence in your subject matter expertise can lead to problems.

    What Cheryl learned: Beware of the curse of knowledge. It’s great to develop subject matter expertise, but when you use your knowledge exclusively to develop requirements or solutions, you’re likely to miss something. Take a collaborative approach and avoid working in silos.

    Paula Bell

    Paula Bell | Paula A. Bell Consulting, LLC

    Paula explains how the fear of sharing bad news can lead to a lack of trust.

    What Paula learned: Be transparent and don’t avoid sharing bad news. Being open and honest about problems lets us do something to resolve the issue sooner and it also leads to developing greater trust.

    David Mantica

    David Mantica | President, ASPE-Training

    David tells a story of how overconfidence in one solution caused him to miss out on a great opportunity.

    What David learned: Don’t get stuck in the weeds. Make sure you pick your head up once in a while and see what’s going on around you. Don’t get caught up in your own hubris; check your ego. You can love what you do and still be open to other people’s ideas.

    Bob Prentiss

    Bob Prentiss | Bob the BA

    Bob shares two mistakes; one personal and one professional that helped shape who he is today.

    What Bob learned: Don’t avoid crucial conversations; the longer you wait, the harder it is to have those difficult discussions. The regret you’ll have is often harder to live with than facing what you need to do. Also, don’t let your ego get you in trouble. Understand that everyone plays a role in the success of the project. We all need to be open and collaborate to achieve success.

    Kupe Kupersmith

    Kupe Kupersmith | President, B2T Training

    Kupe shares a story about how he almost lost his job because he didn’t consider the human side.

    What Kupe learned: Don’t forget the human side of things. Your solutions may be perfectly logical, but if we forget the human side, we’ll meet resistance. Many of us get tripped up when we don’t successfully navigate political waters and take personalities into account. Be aware of the human side of change.

    There are some common themes in what these industry leaders have learned.

    • Act with openness, transparency, and collaboration
    • Check your ego at the door
    • Understand that the human side of change is just as important as the technology.

    I hope you’ve learned something from this episode so you don’t make the same mistakes.

    Listen to the full episode to hear the biggest mistakes made by these eight thought leaders (as well as my own biggest mistake).

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA100.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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA100: My Biggest Mistake appeared first on Mastering Business Analysis.


    MBA099: Assumptions Mapping Nov 22, 2016
    Show notes

    In this episode, David Bland shares an exercise from LeanUX for gaining clarity in times of uncertainty and developing a deep understanding of customer needs.

    

    After listening to this episode, you'll understand:

    • Why the commonly used Build-Measure-Learn loop is backwards
    • How to find the right thing to build in order to learn
    • Why the three lenses of feasibility, viability, and desirability are critical
    • How to run an assumptions mapping exercise to gain a deeper understanding and focus on the right thing
    

    Show Notes

    Assumptions Mapping is a LeanUX exercise that leads to valuable conversations within your team and enables them to focus on what really matters. It allows you to gain clarity and find the right path forward, even in times of uncertainty.

    Through Assumptions Mapping, teams will develop a deep understanding of customer needs and the risks associated with finding a solution to address those needs.

    The Build, Measure, Learn Loop is Backwards

    It’s easy to start with building something, which is why most teams start there. The problem is that sometimes we build just to build. It’s something we do to meet a deadline and you’re held accountable to meet dates.

    Building something and expecting to learn afterwards is often just a dream.

    Instead, start with Learn and work your way backwards. What do you need to learn about the market, the customer, or the problem?

    Build, Measure, Learn loopAfter you understand what you need to learn, figure out how you would measure to learn. Finally, determine what (if anything) you need to build to measure and learn.

    Starting with Learn is much more impactful for the team and helps focus them on building the right thing.

    Prioritizing Experiments

    Many teams get excited about experimenting and Assumptions Mapping helps teams to prioritize and run the right experiments.

    Assumptions Mapping looks at the problem through three lenses; desirability, viability, and feasibility.Venn diagram of desirable, feasible, and viable

    The Desirable lens focuses on the customer to understand if the solution is wanted by the customer. Use the Viable lens to focus internally to understand if this is something we should do from a cost structure, business model, and strategy standpoint. The feasibility lens looks at whether or not we can do it (set up as a team to build it, have the hardware and infrastructure, etc.).

    All three lenses are critical to understanding what to solution build.

    Is it Desirable?

    To identify assumptions around desirability, you can ask a number of questions to generate a discussion around the assumptions we’re making about the customer’s wants. With an assumptions mapping exercise, those assumptions are written on sticky notes and later plotted on a four-quadrant map.

    Example questions include:

    • Who is the target customer?
    • What problem are they trying to solve?
    • How do they solve the problem today?
    • If the customer can’t solve it, why can’t they solve it?
    • What is the outcome the customer wants to achieve?

    Is it Viable?

    To understand the assumptions we’re making about viability, we follow a similar process around questions related to how the solution related to our business strategy.

    Example questions to identify viability assumptions include:

    • What’s our acquisition channel?
    • How will customers come back to use our solution again?
    • How will customers refer us to other customers?
    • Do we understand our competitors?
    • How do we generate our revenue?

    Is it Feasible?

    Feasibility assumptions relate to whether or not we are set up to create this solution. This includes technical feasibility, ongoing support, expertise needed, resources, etc.

    Example questions to identify feasibility assumptions include:

    • What are the biggest technical and engineering issues?
    • What are the legal and regulatory risks?
    • Are there internal policy or governance hurdles you need to overcome?
    • Do you have leadership support?
    • Where does your funding come from?
    • Why is your team uniquely positioned to do this and do it well?

    Mapping the Assumptions

    Once you’ve identified the assumptions in each area (tip: use different color sticky notes for each and another color for those you come up with on your own), map your assumptions.

    Plot the sticky notes on a two-by-two matrix of important vs. unimportant and known vs. unknown. When plotting assumptions on this map, the distance along each important/known line is relative to the next.Four quadrant map of known vs. unknows and important vs. unimportant

    This exercise not only creates a map helping the team to understand what items are the most unknown and important, it also generates a great conversation and creates a shared understanding.

    For identifying experiments, focus first on the top left quadrant; the unknown and important items.

    Run an Experiment

    There are many different kinds of experiments. When you identify an assumption you want to run an experiment against, work to make it more testable by getting very specific.

    From there, design an experiment that will allow you to test your assumption. Depending on the type of assumption, this can mean creating a prototype, a landing page, or price testing, business model testing, engineering spikes, or other ways to test your assumption.

    Assumptions Mapping and the experiments help us to avoid shelf-ware; creating a solution that on one actually uses. It helps us to better understand the solution through different lenses to make sure we build a solution that’s viable, feasible, and desirable.

    Remember that the conversation is more important than the mapping.

    Listen to the full episode to hear all of David’s tips and advice about using Assumptions Mapping and Lean Startup approaches.

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

    Z

    Your Homework

    Get David’s materials on Assumptions Mapping and map your assumptions with your team. Then identify one item and run an experiment.

    Links mentioned in this episode:

    • David’s website Precoil.com
    • Precoil’s Resources and Videos
    David Bland

    David Bland

    Founder & CEO of Precoil

    David is the founder & CEO of Precoil, where he helps both startup founders and enterprise leaders rapidly find product market fit. He’s pioneering a new breed of facilitative consulting by blending together Design Thinking, Lean Startup and Agile to make products that matter.

    • X

    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.

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA099: Assumptions Mapping appeared first on Mastering Business Analysis.


    MBA098: The Art and Science of Influence Nov 15, 2016
    Show notes

    In this episode, David Mantica talks to us about influence and discusses how professionals can successfully navigate any organization to move projects to execution. He also shares several approaches and techniques to improve your ability to influence.

    

    After listening to this episode, you'll understand:

    • Why influence is a key skill for any project professional
    • How to build trust within your organization
    • Why knowing yourself and emotional intelligence are vital to your ability to influence
    

    Show Notes

    The ability to influence is both an art and a science. The art side of influence lies in the need to know when to adjust or pivot in your approach. The science ties into emotional intelligence (EQ) because you need to understand yourself first and the biases that can affect influence.

    Influence is built upon other skills such as the ability to deal with conflict, facilitation, and change management. Without the foundation of EQ and other skills, your ability to influence will be severely limited.

    The pyramid of influence

    Influence vs. Manipulation

    The difference between influence and manipulation is in the underlying reason for making a change. Where influence crosses over t manipulation is when you try to influence people to do things for your own self-interest.

    From a power base standpoint, influencers come from a referent power base. It requires you to have the effort, energy, and charisma to take people from one point to the next step in where you want them to go.

    Trust is what separates the influencers from manipulators. Building trust that what you’re doing is for the good of the organization and its customers will allow you to be more successful in driving positive change.

    Being able to properly articulate why you want to make a change is key to building trust and gaining support.

    The Science of Influence

    When you are trying to influence without authority, you need to start with emotional intelligence. This leads to self-awareness, which allows you to self-manage (awareness of your hot buttons and the ability to control yourself).

    From self-awareness, you can develop situational awareness. This helps you to understand what’s happening in your environment and how you should respond and manage those situations.

    Understanding biases is part of situational awareness because it allows us to better understand the behaviors of others.

    One common bias is the endowment effect. This is the belief that what you own (including ideas and beliefs) are more valuable than those of others.

    Social proof is another common cognitive bias in which our perception is colored by popularity (or lack thereof).

    Understanding cognitive biases allow you to look at the behavior of other people through that lens and approach the situation differently.

    The Art of Influence

    The art of influence starts with understanding what it means to be likable. It’s much easier to influence someone if they know, like, and trust you.

    Likability starts with eye contact, a smile, and asking questions to get to know the other person. It’s about making them feel comfortable and connecting on a human level.

    Active listening also contributes to likability and developing trust.

    From there, focus on your execution and delivery. Showing that you can drive a process forward and create transparency builds a foundation to influence better.

    Coming to the table with potential solutions instead of just problems will help build trust and influence. It shows that you’ve looked at all sides of a problem and have considered actions to take.

    Listen to the full episode to hear more tips on improving your influencing skills.

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

    Z

    Your Homework

    1. Know yourself: Reflect to better understand your strengths and weaknesses and your hot buttons to develop better self-awareness.
    2. Accept Others: Work on getting comfortable with who people are and their strengths/weaknesses. Be open to new ideas and opinions.
    3. Offer solutions: Think through problems and offer solutions without the need for your solution to be accepted.

    These three actions will help you become a trusted advisor and influence positive change.

    Links mentioned in this episode:

    • ASPE Training
    • Wall Street Journal article on Likability
    • David’s previous episode: The T-Shaped BA
    David Mantica

    David Mantica

    President, ASPE-SDLC

    David Mantica has more than 20 years of experience in B2B continuing education. He has participated in and supported the work of numerous certifying bodies including the Scrum Alliance, PMI, IIBA, TrueSecure, and CompTIA. David also is a regular speaker at IIBA and PMI chapters.

    • 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

    .Subscribe on iTunes Listen on Google Play Music Available on Stitcher Radio Subscribe on Android

    The post MBA098: The Art and Science of Influence appeared first on Mastering Business Analysis.


    MBA097: Partnership Between the PM and BA Nov 08, 2016
    Show notes

    In this episode, author and consultant Cheryl Lee helps us to improve the collaboration and partnership between Business Analysts and Project Managers.

    

    After listening to this episode, you'll understand:

    • Why there’s often tension between the Business Analyst and Project Manager
    • What steps you can take to build a better PM/BA partnership
    • How to become an advocate for Business Analysis
    • Why understanding the value of each perspective is important, even for those with combined roles and in Agile environments
    

    Show Notes

    There’s often tension between the Business Analyst and the Project Manager. The Project Manager wants everything delivered on time and on budget while the Business Analyst wants to ensure the project scope is covered with appropriate quality.

    This tension can lead to missed opportunities to collaborate and form a strong partnership between the PM and BA which would benefit the project and the organization.

    With Project Managers more focused on the project and Business Analysts more focused on the product, how can we find a common ground to form a powerful partnership?

    Building Better Partnerships

    The first thing we need to do to build a better partnership between the Business Analyst and Project Manager is to understand the value that each role contributes to the project. To take it a step beyond the role, work to see the value in project management and business analysis.

    Even in Agile where the titles of Business Analyst and Project Manager might not exist, thinking about the skills, activities, and perspective of each of the roles will be important.

    Looking at the value of the outcomes produced by both perspectives helps those with a combined PM/BA role and those without a PM or BA title to understand the importance of each area.

    Once you understand the value of each perspective, identify the integration points; those areas that are shared between business analysis and project management. Areas such as risk management and stakeholder management are common areas shared by both perspectives.

    Advocating the BA Role

    As the Project Manager role is more standardized and often better understood, the issue of not understanding the value is usually in the area of business analysis. Misunderstandings such as this can lead to undervaluing the Business Analyst.

    Misunderstandings about the BA role are no one’s fault; it’s simply a fact. Business Analysis hasn’t been around quite as long as project management and many people are not clear on how the BA adds value.

    To address this, Business analysts need to become advocated for the role. One way to become an advocate for the BA role is to start a community of practice to share knowledge and elevate skills. These sessions may draw in non-BAs to learn more as well, helping to create transparency as to what a BA does and change perceptions.

    Don’t Short Change Your Role

    Business Analysts are often asked why it takes so long to get requirements. We’re sometimes pressured to reduce the amount of time it takes to elicit and document the requirements.

    Giving in to this pressure by arbitrarily reducing the amount of time you truly need to elicit quality requirements can lead to missed or poor requirements and have negative impacts to the project.

    One way to address this is to discuss lessons learned on similar projects in which timelines were reduced and requirements quality suffered.

    Another approach is to write down all of the analysis activities that it will take to deliver the requirements for your project with sufficient quality and meeting the needs of stakeholders. Make sure to consider not only the activity itself (such as a requirements workshop), but also any preparation activities and trailing activities needed.

    Use the list to get a bottom-up estimation of the time needed and discuss the activities with the Project Manager and the team. This will lead to a better understanding of what you do, why those activities are needed, and why you need the time to do things properly.

    Listing activities needed by both the BA and the PM can also help to identify integration points and areas in which the BA and PM should work together.

    Listen to the full episode to hear more of Cheryl’s advice on improving the BA/PM partnership.

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

    Z

    Your Homework

    Make time for business analysis. Create a to-do list for analysis activities needed to achieve the desired outcomes and share it with the Project Manager. Having a conversation about the needed analysis activities and their value leads to greater transparency and can help identify opportunities to partner on some activities.

    Links mentioned in this episode:

    • Cheryl’s book, Effective PM and BA Role Collaboration
    • Previous episode with Cheryl’s co-author, Ori Schibi
    Cheryl Lee

    Cheryl Lee

    Cheryl Lee is a certified Professional in Business Analysis (PMI-PBA), Project Management Professional (PMP) and Certified Business Analysis Professional (CBAP), and the co-author of the book “Effective PM and BA Role Collaboration”.

    Cheryl is also the President of a Toronto-based consulting firm that offers consulting and training services within the areas of business analysis, project management and change management. As a highly experienced business analysis and project management practitioner and trainer, Cheryl has mastered the ability to harmonize the PM and BA roles in order to deliver seamless and successful implementations.

    • 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.

    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 MBA097: Partnership Between the PM and BA appeared first on Mastering Business Analysis.


    Previous 1 16 17 18 19 20 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
    footer-logo

    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