A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it’s a 23rd of a sprint
A: But the time before that it was 19
B: Then for you at the time it was 1/19th of a sprint.
A: But how long is it really?
B: We answered that.

— Tim Ottinger (@tottinge) July 6, 2018

Here are a couple tweets from @GoldrattBooks, an interesting follow for insights on operations, DevOps and process improvement.

DevOps explained using ToC Logical Thinking Process https://t.co/BCdDUDb5Db @kesor6 #DevOps #tocot pic.twitter.com/Wh7R2NNicv

— Goldratt Books (@GoldrattBooks) July 11, 2018

“Features have no value until they are in the hands of a user and being used for a productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.” https://t.co/49fzipMGTZ #tocot pic.twitter.com/4r0t7UrEUN

— Goldratt Books (@GoldrattBooks) July 11, 2018

No digest is complete without some words to live by…

pic.twitter.com/EJOSOizFd9

— Wisdom to Live (@wisdomtolive) July 4, 2018

Think of a book you’ve read and enjoyed which was later interpreted as a movie. With the book, your interpretation of the appearance of the settings and characters is a product your imagination, which is shaped by your unique life experience. Every reader of that book comes away with a somewhat similar, but different perspective.

An author can narrow down some of the variance in interpretations by adding more descriptive detail. Think of a book you’ve enjoyed for its vivid descriptions of setting and depth of character development. This can be great for a riveting novel that we wish would never end.

Perhaps, upon leaving the movie based on a book you’ve read, you considered (or commiserated over) how different the characters and the scene were from how you’d imagined them. Your interpretation of the words in the book is as valid as anyone’s. It just didn’t match those of the producer of the film, and possibly, the author of the book. This makes for interesting discussion and critique.

In the book’s cinematic version, with the addition of the audio and visual elements, all viewers come away with a shared mental image of the appearance of the settings and characters, because the additional sensory dimensions make them more explicit. Similarly, visuals, such as pictures, diagrams or other types of models can be helpful in our business communication because they eliminate much of the “imagination,” or ambiguity of words, making meaning more explicit. Visuals serve to calibrate the natural differences in our mental images.

Now, unlike that great book or movie, most of us don’t read business documents such as  a requirements specification for enjoyment. And unlike the book, there can be significant repercussions when one reader’s interpretation of the content varies widely from another’s. The Big Thick Document (BTD) is a product of the notion that increasing a document’s length to add more detail will improve the communication value of the document. Unfortunately, the opposite is more often the result because the longer document is, the:

1. Less likely to be read
2. Less likely to be understood if it is read
3. More likely errors or omissions are to be overlooked, as readers tend mistake length and detail for precision and accuracy.

Thoughtful use of visuals – even, and especially in rough or early drafts – adds a dimension of “understandability” to the ideas expressed in documentation that is not possible in a mostly text-based format, and at very little additional cost. In fact, often it is more work manipulating language to describe something than it is to represent it visually. To this end, a white board or a blank sheet of paper and a drawing utensil are valuable tools when it comes to working through ideas to establish common understanding.

A few questions we may ask to help us optimize our efforts:

• What can we give business stakeholders who want to confirm for us that we’re on the right path that isn’t overwhelmingly long and difficult to decipher?
• What can we give delivery team members that, first, summarizes the details and provides context, then, expresses the details in as easy a form as possible to understand and use to do their work?
• How can we strike an acceptable cost/benefit balance in doing these things?

Featured image by Bartosch Salmanski

Ryland Leyton

Ryland Leyton recently released his book, The Agile Business Analyst: Moving from Waterfall to Agile. Over the years, Ryland has provided training and mentoring for events and individual members of the Greater Atlanta Chapter of IIBA, so I was thrilled to see him take pen to paper and share his insights through a medium with broader reach.

Ryland agreed to provide some additional information and background on the thought process behind the book for Practical Analyst readers, via the Q&A provided below. Written especially for business analysts operating in, or transitioning to an agile delivery environment, I recommend The Agile Business Analyst as a solid candidate for your professional development reading list.

What was your motivation for writing The Agile Business Analyst?

In September of 2014 I had volunteered to give a presentation on the Agile methodology to our Atlanta IIBA chapter at the Boot Camp event, (a professional development day). Agile has been a big topic for the BA community and by this point I’d had some experience working in it with a group that was very invested in staying agile, but in bringing stronger BA practice to the team. Things were going well there so I chose I could speak to the subject for the chapter event. I put a lot of work into preparing for it – the session was planned for 3 hours, and we stretched to almost 4!

People were very responsive to the material – I could really feel the hunger for the information! It seemed to me that the audience was really connecting to the subject, and at several following events people kept asking questions that I just couldn’t answer in a brief conversation.

I was actually in the right place in my personal and professional life for a big project, and I decided to use my original presentation as a foundation for a full book on the subject.

Who stands to benefit the most from The Agile Business Analyst, and how?

The core audience for the book is, as the title says, the BA who is moving from the waterfall approach to the agile approach. They’ll find it speaking to them directly in terms of knowledge about agile, skills the BA should have, and how the BA fits into the agile SDLC and partners with other team members. After reading it they’ll have a thorough grounding in agile, understand the roles & responsibilities of the BA as well as those of their teammates.

The book is also good for product owners, managers, anyone new to the agile space, or scrum masters and development professionals new to working with a BA on their team. If you’re looking for a good practical primer on agile that is written in an easily accessible way, I think this book can cover it for you.

Of all the topics available in solution delivery in general, and business analysis in specific, what drew you to the topic of agile for business analysts?

Really, just the major demand for the subject that was so overwhelming wherever I went. People wanted to know about one agile topic or another every time I talked to a group. Also, the “agile” practitioners weren’t making it easy for BA’s to fit in or acquire knowledge. Most sources seemed to just say “we don’t use BA’s”, and expected the conversation to stop there.

What was the most the most rewarding aspect of writing the book? The most challenging?

The most rewarding thing has truthfully been people reading it and letting me know it helped them in their work – that they got a lot out of it, either a good grounding in agile, or something they hadn’t considered before. It really was written because I felt a calling to add something to our community on this subject, so I feel good when I know I’ve hit that mark.

There were two parts that were really challenging in the process of creating the book. The first was getting the first draft done without editing myself too much. Friends from other fields who have done their own writing encouraged me to just write anything I thought of first, and edit as a completely separate activity. I had to get all the subjects I thought I wanted to cover completed, organized enough with good common threads, and then make myself give an incomplete product to a selection of close friends and agilists who could give me their time to read an unpolished manuscript as well as give me feedback on it! The second most challenging thing was applying the agile principle of “minimum viable product” (MVP) to the book itself. I always found more things I was interested in writing about…but I had to stop somewhere and call the book “done”. At least, for the first edition! I had to remind myself that the book had no value in the community while it sat only on my desktop! I wanted to get it out there, start seeing how it did in the real world, and log some improvements for the future. When you’re writing something that you feel really represents you in your professional life, that can be a hard line to identify.

What have you’ve learned about the topic through your detailed research for the book, that you didn’t know when you started?

The second part of the book has two case studies in it – the same project looked at through the waterfall view, and the agile view. When thinking about the agile view I spent a lot of time considering just how different agile was, and what massive opportunities for interesting BA and project practice, are present in agile. The agile project could have gone in radically different ways than the waterfall one. I deliberately chose to take a mostly “mainstream agile” approach – if there is one – versus the most radical of the choices. I spent a lot of time thinking about the concept of minimum viable product (MVP) in both the case study, and in other projects I’d worked on. Just how minimal can you get before you release something into the world to start the learning cycles? How close to the bone can you make your MVP in a project? It’s something I still think about a lot as I’m working with clients.

Let’s talk about your aspirations for the book. Jumping ahead 5 years – what would you like to be able to look back and say about The Agile Business Analyst?

I would love it if the book were well enough received that it becomes a staple of the agile BA field. I’m expecting to do a second edition at some point in the future to expand on several topics as I receive feedback and continue to have my own experiences in my agile practice, so having that out would by then is also an aspiration.

Any other advice or words of wisdom would you like to share with Practical Analyst readers?

Always keep interested in something in the BA field, and try to do work that aligns with your professional passions. You’ll love your work!

Let’s face it, lots of software projects continue to fail every year, even after so many advancements in the theory and practice of software development and business analysis. As a coach and mentor of business analysts, I’m often presented with many horror stories, such as:

Image credit: Duncan Allen

• A internal software project that seemed to be going well until the day the BA offered a demo of the solution to the project stakeholders only to hear that a big miss would prevent the solution from going live until an expensive architectural change was implemented.
• A customer-facing application that passed UAT but got hundreds of support tickets submitted on the first week because an enhancement caused a common task performed by users to go from requiring one click to multiple steps to complete.
• More than 50% of the functionality included in a release remained unused, while change requests continued to be submitted, indicating that the team heavily over invested in new features when they could be optimizing existing workflows.

Why is failure so common? What can be done about it?

After working on countless complex software projects that delivered great business value, here’s what I learned about the reasons for a project to succeed:

Reason #1: You do your homework

As the person responsible for the solution requirements, you need to develop a deep knowledge of the business needs your solution is supposed to address. A workshop with stakeholders where you put up sticky notes on walls won’t cut it. A series of interviews in which you ask a series of yes-or-no questions, or the interviewer evades your probing questions and say, “here’s what I want” won’t cut it. Focusing your attention on individual features as opposed to how your solution will fit into the day-to-day activities of your end users won’t cut it.

Specifying a winning solution requires investing sufficient time to analyze the problem and the constraints around it, and to understand quality as the customer sees it. While a mediocre BA may spend lots of time defining requirements for a solution full of bells and whistles based on how he or she defines quality, a successful BAs dedicates time to investigating what capability are truly valued by customers–which may be entirely different from what they *say* they want, as illustrated in this diagram by David J Bland:

.

It all starts with asking the right questions to the right people. Successful BAs do their homework to truly understand who their key stakeholders are (from the people writing the check to the ones who will have to use the application to perform their job), and learn in detail what job the software is being hired to do for these audiences. They also put significant effort into determining what initial hypotheses they need to validate during the analysis phase in order to avoid negative surprises when the solution is finally deployed.

Reason #2: You see the value of storytelling

Successful BAs see the power of storytelling. They’ll spend hours looking for a shorthand story that will make their ideas memorable, because they understand that using stories to communicate ideas helps their audience retain and commit to the message they want to deliver.

Let’s say a stakeholder is insisting that you add a calendar feature to the capabilities of a content management system you’re specifying. You’ve done your homework, and speaking to various user groups determined that, without integration with Outlook (the email application the company uses), no one will want to use the calendar, because it would be a pain to manage two separate calendars. After concluding that Outlook integration is out of question due to time and budget constraints, you have the difficult task of convincing the stakeholder that his “pet feature” is not going to produce any value and therefore should be left out of scope. Instead of just giving the requester the facts you’ve compiled, you’d know to start the conversation describing how Sally from Marketing would get frustrated and abandon the calendar once she realized she was having to input each of her planned Facebook campaigns twice. Why is this important? Because we’re human beings, and that means we are influenced by far more than hard data. Storytelling helps us appeal to the emotional mind that needs to be convinced along with people’s rational mind.

Reason #3: You understand the importance of building relationships and becoming a good influencer

In order to succeed as a change agent, a business analyst often needs to rely on the power of influence to gain access to the right stakeholders, postpone a deadline when more time is required to fully understand the problem or solution space, or get an opportunity to present her recommendations to the real decision-makers.

Successful BAs never try to “sell” their ideas “up the chain” until they have paved the road forward by developing relationships, allies, and supporters for their proposals at the lower levels of the organization. They know how to sell their ideas in private, welcoming input and advice from various sources in order to get them to develop a sense of co-ownership. They make people care by appealing to the things that matter to them, transforming their stakeholders into charged up supporters that help move their agenda forward.

BAs who consistently deliver successful projects aren’t just lucky. Because they did their homework, they have an ironclad case for their specifications. Because they spent time developing a story to go with their recommendations, they have a much easier time getting their ideas heard. And because they they’ve found and nurtured allies in different parts of the organization, they’ve turned colleagues into allies invested in moving their agenda forward.

1. A clear purpose (what we’re trying to accomplish)
2. A reason to attend (why we need you there)
3. An agenda (a plan for achieving the purpose)
4. How/What to Prepare (how you can prepare in advance to ensure our time is well spent)

1. Purpose

Each meeting should have a purpose or goal, and that purpose should be clearly explained in the meeting invitation.

For example,

“The purpose of this meeting is to determine the tasks and estimates of effort and time required to add feature W to the scope of Project XYZ.”

Stating the purpose in the invitation gives invitees a sense of how their time will be spent, and that the meeting organizer has put some thought into it beforehand.

When a vague, general topic is provided in lieu of a clear purpose, attendees may come with differing ideas on what is to be accomplished around that topic area. This can make meeting management difficult, and participation frustrating for attendees.

Having a clear purpose enables the facilitator to manage to the purpose. If conversation starts to meander off track, he/she can point to the stated objective to get dialog back on course.

2. Reason to Attend

Invitees may have conflicting obligations at a given day or time. To help them decide where there contributions are needed most, it is helpful to explain in the body of the invitation why the invitees have been included on the invitation.

For example,

“You are included on this invitation because you are member of the Project XYZ team,  or because you have subject matter expertise needed to reach our decision/achieve our objective.”

It isn’t necessary to note reason by individual, we just want attendees to know we didn’t use a scatter gun approach, and each attendee is needed to accomplish the meeting’s purpose.

While it is a good practice to try to limit attendees to those required to reach a decision, or achieve the meeting purpose/objective, you may also want to appeal for assistance in identifying additional attendees that you may have unintentionally omitted from the invitee list, or not known would be critical to the discussion.

Here is an example I might use:

“We’d like to limit attendees to only those required to reach our stated objective(s), but if you notice anyone missing from the invitee list who should participate, please let me know, or forward the invitation to those individuals.”

3. Agenda

An invitation should always include a meeting agenda, even if it is tentative or rough.

Providing an agenda demonstrates to invitees that there has been some thought given to an approach for achieving the meeting purpose or objective. By providing an agenda, attendees can provide feedback on additional items that might be added to the agenda.

Here are a few good practices for meeting agendas:

• Provide a brief but adequate description of each agenda item. Ideally, there will be a logical flow to the agenda items.
• Include approximate amount of time for each item – this helps time box and keep the meeting on schedule.
• Include names next to any assigned agenda items requiring preparation or presentation on the part of attendees.

4. How/What to Prepare

Let attendees know of any preparation required on their part to help the meeting run smoothly, and enable to objective of the meeting to be achieved.

Examples

Below are a couple examples that illustrate use of the four critical components. As you can see, the invitations does not have to be long to include these elements, but readers will come away with a much better idea of how the time will be spent, whey they are needed, and what is expected of the. If you find these examples useful, feel free to borrow or modify to suit your purpose.

Example 1 – Invitation to a working session

The Business Analysis team has been considering ways to make our requirements product easier for business stakeholders and downstream IT teams to understand and use. We’re also examining our current process and documents for redundancies and other inefficiencies for opportunities to improve.

With that in mind, the objectives of this meeting are to:

1. Initiate an ongoing, cross-team dialog on how to improve the communicative value of requirements
2. Gather feedback on the current requirements process and documentation, and
3. Introduce and discuss a few ideas for improvements we’ve been considering

You’ve been included on this invite as either representing a group that is a direct consumer of requirements, the PMO, or IT leadership. I know there are many others that would be interested in the discussion, but in order to be productive, let’s try to keep the group small, initially.

As agenda items, I’ll walk the group through a few informational slides (~15 min.), and the balance of the time will be for discussion and a few minutes for next steps (~45 min.). You might consider this a requirements gathering session for requirements!

You don’t have to prepare anything specific, but please be prepared to discuss your (and your team’s) thoughts on opportunities to optimize the requirements process and documentation to your benefit.

Thanks!

[Meeting Organizer]

Example 2 – invitation to a community of practice meeting

This invitation is to serve as a placeholder for our bi-monthly Business Analysis Community of Practice (BACoP) meetings through next June.

You’re included either because your job title falls under the broader “business analysis” umbrella, you have managerial responsibility over analysts, or you have otherwise expressed interest in participating in the group.

If you’d like to be removed from these notifications, or if you know of someone who would be interested in participating that is not on the distribution list, please let me know and we’ll edit the list accordingly.

Bi-monthly meetings will typically follow this agenda:

• 11:30 – 12:00 – Lunch; visiting and networking time.
• 12:00 – 12:15 – Welcome, General announcements or business re: training opportunities, networking opportunities, etc. Recognize first-time attendees.
• 12:15 – 12:45 – Presentation/Discussion topic (a tool, technique, a day in the life of a BA in a given part of the company, a business analysis topic of interest, guest speaker, etc.) We’ll plan to rotate this among groups.
• 12:45 – 1:00 – Wrap-up, suggestions, present/vote on options for next meeting presentation topic, clean-up.

We will update each occurrence with details on the topic of discussion and any logistical changes during the month of the meeting. We just wanted to make sure this was on your calendar in advance so you can plan to work it into your schedules.

Lunch will be provided at community of practice meetings.

Thank you for your participation in and/or support of the community of practice, and we’ll look forward to seeing you at upcoming meetings!

Regards,

[Meeting Organizer]

Featured image credit: Richard Rutter.

If human communication and human memory were perfect, we may not need deliberation and documentation of requirements. Alas, neither is close to true. It is the iterative exercise of modeling requirements, and then documenting them that enables shared understanding to be affirmed, and then shared with those who use requirements to guide design, construction and quality assurance. Requirements are the link between concept and product, and an important standard for measuring solution success. 

Our supervisor had little patience for poor writing, seeing it as a fundamental professional skill, especially for business analysts. Over time, and the course of many reviews resulting in red mark-up throughout his documents, management lost patience with his deficiency and lack of progress. Unable to see beyond the dread of his next document review, my colleague began to lose confidence in other aspects of his work, and his overall performance faltered. The eventual results were as expected; the team lost a skilled contributor, and the analyst lost a promising career with a great company.

I’ve often reflected on this, with empathy for both sides. A profession as highly dependent upon effective communication as business analysis must require good written language skills. However, written language is only one form of communication among many available to the analyst – and an inherently vague and ambiguous one, at that.

How would I handle a situation if I were the supervisor of a business analyst with similar struggles? To begin,  I would ask myself a few, basic questions to help me decide how to to manage the situation and the individual:

• Is the analyst’s documentation otherwise correct and complete?
• Is the documentation well-suited to its purpose and easy to understand and use?
• Is the analyst making a sincere effort to improve?

Business analysts create requirements models in order to record and transfer important knowledge that business stakeholders depend on to validate the accuracy of the requirements, and  delivery team members depend on to design, develop, test and implement a solution based on those requirements. Documentation, at its core, is a communication tool. As such, ease of understanding and communicative value are paramount.

Poor grammar and spelling that cause a requirements model to be inaccurate, or difficult to understand and use, are serious because they negatively affect the documentation’s ability to serve its purpose. An otherwise solid, easy to understand document with some errors in grammar and spelling, is not as serious. In either case, poor grammar and spelling should be included in the offending analyst’s professional development plan, and improvement should be encouraged and expected.

Below are my words of  counsel to the analyst or the manager who finds him or herself in a similar situation.

If you’re a business analyst who struggles with spelling and grammar, here are a few recommendations that may provide short-term relief, while providing evidence of efforts toward long-term improvements.

• Direct reviewers’ focus to the substance of the documentation and not the form. Grammar and spelling suggestions are valuable and welcome, but can be part of the finishing process. During the course of working sessions and early review meetings, ask participants to focus on correctness and completeness of content, and ensuring shared understanding.

• Be intentional about showcasing the things you’re really good at, and partner with other analysts in “buddy” fashion to help them by applying your relative strengths to areas of team weakness. In my colleague’s case, he could have offered assistance and coaching on how to effectively model flows and diagrams in return for extra assistance with grammar and spelling.

• Make improving grammar and spelling a pillar in your professional development planning, and communicate that desire and evidence of action to management. To my recollection, my colleague did ask for assistance in reviewing his documentation and making corrections before others saw the documents, but he did not demonstrate or provide evidence of a real intent to improve. Management is much more likely to extend grace in evidence of a plan to improve, and incremental improvement over time.

If you manage someone who struggles with spelling and grammar, here are a few recommendations that may enable you to avoid parting ways with an otherwise strong performer.

During my time managing business analysts, I adopted the following stance on grammatical errors, specifically: If meaning is not obscured by faulty grammar, punctuation & spelling, coach it up. Don’t let it hold up progress. Perfection comes at too high a price.

With that in mind,

• Focus on the overall value of the documents as communication tools, grammar and spelling aside. Is the document correct and complete? Does it effectively fulfill its purpose? It it easy to understand and use? Focus on the effectiveness of the documentation in meeting its intended purpose instead of honing in the distraction of poor grammar.

• Recognize and acknowledge (both privately and publicly) the analyst’s value to the team and the organization and  draw attention to his/her strengths.

• Coach the analyst. Work with the analyst to set goals and hold him/her accountable for improvement efforts. Provide professional development opportunities to bridge the performance gap.

Developing people is every bit as important as managing the flow of work through the production pipeline, and every bit as satisfying, especially when you’re able to help someone who has struggled in some aspect of performance to make a break through.

That said, while I am sympathetic to those who are struggling in one area but who have offsetting strengths in others, and who show a willingness to improve, the manager, as steward over the quality of his or her team’s work, must be prepared to make difficult decisions if, after sustained efforts and patience, quality of output does not improve.

What is your stance on handling errors in writing, and how might you handle a similar situation?

Featured image credit Eli Reusch.