The Elevator Pitch is to the Requirements Benefit is inspired for you by the following tweet: ”@EntMagazine How to pitch your business in 60 seconds or Less: entm.ag/t52rAO by @carminegallo”
I’m out on my own now. I left the giant Fortune® 50 company I worked for. I’m talking to small companies about potentially joining them full time and I am loving the freedom. Beyond that I am immensely optimistic about the opportunities. So for many reasons you are seeing updates to the site, and for many reasons this post from Entrepreneur Magazine was engaging and relevant for me.
Relevant in what ways you ask?
- I have to be able to clearly articulate why I left a very intriguing and growing Fortune® 50 eCommerce team.
- I have to be able to articulate what I am doing now to add value to new clients (i.e. people that can give me money so I can pay my bills).
- I can always improve the way I approach business analysis (have you noticed I derive inspiration and ideas from many verticals and disciplines?).
After reading this article, I modified Carmine’s list of four questions into what a BA (whether Agile or Waterfall) should be asking of their stakeholders.
- What do you do? –> What should it do?
- What problem do you solve? –> What problem does it solve?
- How is your product or service different? –> How is it different from what is done today?
- Why should I care? –> What business value does it add?
Please note, I did make “stakeholders” generic above. I did this intentionally. I originally wrote “business stakeholders” but I realized in fact, that the IT stakeholders are almost more important because of questions #2, #3, & #4. As a BA we know all too well that our IT stakeholders are phenomenal at telling us “how it should do it” – but are historically horrid at telling us the answers to those remaining questions (why it should do it, the problem solved by doing it that way, how we can differentiate by doing it like that). Getting the true problem statement, differentiator, and value proposition out of the IT constituents will help us as BAs convey the importance and value of more technical requirements.
The Gist of the Article
Essentially the article, “How to Tell Your Business Story in 60 Seconds or Less,” conveys the importance of entrepreneurs having the ability to clearly summarize the value proposition of their new venture to investors in under 60 seconds. It really is important. I’ve had a start-up of my own and you have to have the canned statement ready when people ask you what you do and why they should believe in/trust you. (I can assure you it was not my dashing good looks that got me contracts when I was a geeky college student with a web development company.) You almost have to have the story embedded into your DNA, its like having a tape recorder as a part of your voice-box and when someone asks you, you just hit rewind and then play again – spitting out the same paragraph over and over again. Carmine does a good job of emphasizing the importance of this, and offers a good suggestion for summarization (as noted in the list of 4 questions above).
The General BA Tie-In
I can’t tell you how many times I have spaced out listening to a stakeholder. And less attractive for me to admit, I don’t even want to imagine how many times people have spaced out listening to me talk about a requirement. (Notice there is no “s” on that – I truly mean a single requirement.)
If you, as a BA, cannot articulate the intent and benefit of a requirement in less than 60 seconds then you’re not doing the best job you can do.
- You won’t be able to effectively communicate with your executive sponsors or executive management if they ask about it. (Communicating at ALL levels of the organization is a paramount skill to possess.)
- Your developers will tune you out when you start talking. (They want direct, concise, to-the-point explanations of what they need to do/why they need to do it.)
- Your business stakeholders will likely perceive you as overly verbose. (They need the confirmation that you “get” what they are saying, what they need, and that you can articulate it for them. Not to mention, if you don’t elicit all of this information from your business stakeholders you are not doing your job,)
The Agile Tie-In
Requirements in agile are most often depicted by User Stories. They are a STORY – using the guidelines from this article allow you to frame up the majority of the information you need to convey within a user story, help you partner with the product owner in order to understand true business value, and tell a story about the feature/capability of the system.
User Stories are also meant to foster the conversation. Remember, agile is about “conversation” not “documentation” – so internalizing these key benefits from an elevator pitch along with the primary aspect of a user story (actor, action, benefit) you can nail the communication during daily scrum sessions when team members have questions and you can succinctly summarize for team members during story review and story grooming sessions. The quickness of the conversation is also important. Iterations/Sprints are meant to be short, and very moment is valuable as you want as many minutes available for producing working software as you can get. The more concisely the requirements can be articulated, the more efficient the team, the higher the velocity, and the more business value gained.
Lastly, the User Stories should (if at all possible) be articulated from the end-user point of view. Asking these questions will get you to that level of detail and allow you to spin something around to showcase business value and benefit.
More context to come on my recent professional transition, for now I leave you with a note wishing you Happy Holidays!
Continue Reading
The second set of eyes will assist in identifying gaps, inconsistencies, and clarity issues. That feedback is invaluable!
In the post Dorie elaborates on 5 key points in a general way, here I have borrowed her 5 key headlines for things to avoid in 2012, and elaborated in relation to the Business Analyst role.
The August Book Club for 
