Skip to main content

Tag: Assessment

Getting the “User” out of User Stories

In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirement within agile teams.

Most seem to be a using the standard phrasing construct for his or her stories:

As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?

Because the “User” clause is so simple, I see many teams who fill out their user stories in a by-rote fashion. They’ll literally have hundreds and hundreds of user stories, features, themes, and epics and all of them have “User” as the user.

I think they’re missing a wonderful opportunity to make their user stories, well, more usable and more customer-centric. That’s where I want to go in this article.

The “User”

I consider the user clause in the user story to be a “mini persona”. I’m not a UX expert, but to me a user persona is a description of a user, or better yet, one of your customers. It gives sufficient background on them, their experience level, their perspective, and their problem space, that it helps someone to “visualize” the specific customer.

From a software perspective it helps with all aspects of software delivery. Most importantly it helps us in creating the customers experience in I using our products.

A Story

In 2009 I joined a company that was implementing Scrum to deliver an email marketing, SaaS product. The company’s name was iContact and if you’ve followed my writing, you’ve probably heard about them before. When I first joined, I had a fast paced challenge to ramp up quickly.

Sometime in my first few days, I overheard a couple of Scrum team members talking. As I got closer, they seemed to be talking about me – Bob.

One of them said – It’s not clear to me whether Bob would approve of the design of this feature. It assumes an awful lot of application knowledge when setting up the report template.

Another replied – I think Bob is a bit smarter than you’re giving him credit for. Sure, he’s managing a small business and is overloaded with everything that is involved in that. But he’s a 40-something, college grad, with solid technology and computer skills. Point is – I think he’ll be able to quickly “figure it out”.

Still another replied – I disagree. Bob is not that smart and I believe he’s more technology phobic than literate. Remember, he had to call Geek Squad to install and setup his computer system. He’s fairly clueless, so we’ll need to make it more intuitive.

At this point, I wanted to interrupt their conversation and set the record straight that (a) I certainly wasn’t clueless, (b) I wasn’t technology phobic, and (c) that I didn’t appreciate them talking about me in the hallways.

But then it dawned on me that they weren’t talking about me. Whew! They were talking about the customer Bob, or actually our persona of a customer which we named Bob. I was incredibly glad that I didn’t embarrass myself 

Persona’s

My story actually helps define a great deal of the intent behind develop customer persona’s within your design teams and then sharing it across your agile teams. It helps the team to start to understand the customer. By giving them just enough information to put themselves “into” the customers’ perspective.

In this case, one of our personas was named Bob. Bob had a particular profile with respect to his background and needs for the Small-Medium sized Business eMail marketing tool we had built at iContact.

What was even more exciting was the fact that the team was talking about Bob as if he was real. And they were actively considering him, his unique perspective, and his needs for the system as they built out new features. That’s exactly the point of developing the personas in the first place.

There were Five

In our case Bob wasn’t alone. We had developed a set of five personas to represent key aspects of our customer base. For example, one of the personas was very well educated and the other had a high school diploma. One of the personas was relatively comfortable with computers and technology and one of them was not—being simply a storekeeper trying to “dip their toe” into email marketing.

We hung printouts of the personas all over the place to remind everyone of “who” are customers were and “who” were building our products for. That’s another reason that conversation was going on, we had had socialized our personas so well that they became almost real people.

Not just for design

And the personas didn’t simply stop at design. For example, our testers found them incredibly useful in determining what and how to test. We were constantly using risk-based testing techniques and prioritizing our testing. When decisions on what, how and when to test were being mad, we often examined the personas—knowing that we had to keep our customers “whole” as a part of our testing efforts.

Here’s a wonderful article that speaks to this aspect of persona development.

Wrapping up

So instead of stories that all looked like this:

As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?

We had stories that looked like this:

I’m Bob
I want – Feature or Functionality
So that – I can achieve very specific goals for my business

As well as stories for Jane, Todd, Beatrice, and Sam.

You might think that it doesn’t make a difference. But I found that “putting on the hat of the customer” makes a great deal of difference in how we:

  • Envisioned
  • Prioritized
  • Designed
  • Built
  • Tested
  • and Deployed

Our products. In the end, it’s ALL about the customer. And while we say that, personas make it much easier to envision who they really are.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

The Key to Success is MEASUREMENT

Every line is the perfect length if you don’t measure it.”
Marty Rubin ― 

On Saturday June 14th I will be competing in the 7th Annual Paddle for a Cause to raise money for cancer patients via the Dean Randazzo Cancer Foundation. The race is a 22.5 miles around Absecon Island through the back bays, inlets and ocean. If the race could be boiled down to just one word it would be—grueling. It was designed that way to reflect the fight against cancer. The Stand UP (SUP) Paddleboard race is so demanding that you have to commit to a strict training schedule or you simply will not finish. For those who do finish, it takes over five hours to complete and the time is chock full of physical and psychological challenge.

When training for the race you have to measure everything. Your stroke count, your fluid intake, your sleep, the tides, the winds, the weather patterns, the air temperature and the ocean conditions. It can be a highly dynamic task. The measurement tools of this trade are predominantly a Garmin watch which allows you to set and record various parameters as well as a good friend who will keep your stroke rate honest after two hours of hard paddling. In the figure below you can see a snapshot of one of my recent training sessions and the parameters that we (me, my Garmin and my trusty friend) recorded.

cgallaher June6

The quantified self-movement takes on a whole new meaning when you are three hours into a “grueling” paddle, especially when you are alone (without the friend this time) and nearly two miles off the coast. It is at that moment when you not only realize how critical the training measurements and tools really are, but you also truly understand the value of the metrics as it relates to the leading and lagging indicators in relation to your performance (and to their ability to bring you back to shore).

For example, the metrics tell you were you are in the present, the lagging indicators tell you where you were in the past and the leading indicators tell you where you will be in the future. So, if I want to look at my present performance, I would read the metric for distance paddled. If I want to see how my performance has been since the start of the race, I would look at the lagging indicator which would be my average speed. If I want to know where I will end up in the future, I would look at a leading indicator which would be my current pace in terms of miles per hour.

The point is this: The key to any success is MEASUREMENT. It shows you where you have been, where you are now, and where you have the potential to go tomorrow.

Business leaders are no different than Stand UP Paddle athletes. Once you sift through all the noise (weather, rough surf, market dynamics, competitive landscape), there is always one thing that can be counted on and this is our ability to measure the right things at the right time. Measurement done right is one of the highest leverage activities any individual or organization can perform and the single greatest asset in driving improved performance. Find any successful athlete or business person and you will find someone who has mastered measurement.

To test the power of this assertion, pick one habit that you want to change and really start to measure it. Place a defined metric against the habit and then track your results. For example, if you want to walk 10 miles per week, write the number of miles walked on your sneakers after each workout. If you want to improve your project performance, start with something simple like measuring the amount and the average duration of open action items. Another key point to remember when selecting a metric is that you want to utilize the “measurement” for the purpose of improvement— not to make judgments or to prove a point. Measurements that are property selected and executed can truly optimize efficiency and create positive performance for everyone involved.

When I make my 22.5 mile paddle around Absecon Island in a couple of weeks, I will be relying on my training— my methodical measurements over time— to bolster my confidence and to sustain me through tough seas.

Don’t forget to leave your comments below.

It all Happens from the Get Go – 7 Planning Steps to Achieve Measurable Results

Business leaders need to ensure that planning and implementation is focused. A well thought-out planning and implementation approach considers linking strategy, tactics and operational needs. It includes considerations for key business impact zones (productivity, tools, people and culture) and the outcomes required for solutions to business problems.

Consider the business objectives, the process and the work approach that must be used to successfully achieve results in an organization. Results should be resource-driven beginning with shared thinking and consideration of the challenges that need to be addressed. Call them points of pain. All businesses have them and every business leader knows it.

A checklist would be handy at this point. Consider common business challenges such as issues with focus and direction, trust, communications and collaboration, productivity, effectiveness and efficiency, process and work procedures, outdated equipment and tools, people experience, skills, beliefs, values or even blame-storming. No matter the issue, they all add up to one thing – a negative impact, something a business leader seeks to avoid.

Here are 7 steps to consider when planning for measurable results:

Step 1. Understand your business priorities

What five things are on the strategic agenda of the organization? Why are they so important to the business? In what way can your team make those items happen? If you can answer these questions you are on the path to good business leadership thinking.

Step 2. Identify the challenges

What are the points of pain? What are the key challenges? How are these challenges impacting the business? Can we qualify and quantify the problem? Have we considered the impact to productivity, our tools, people and culture? What are the overall impacts and ripple effects to the organization? Write a clear and concise business problem statement that everyone understands. Share that statement and engage in shared thinking and creative solutions with your people.

Step 3. Determine key solutions

Throughout the process, encourage teams to assist you in solving the business problems. Be careful here, as coming up with ideas on how to solve business problems does not mean implementing solutions. Provide support and insight to people whose natural approach is to roll up their sleeves and jump right in. At this point, as a business leader, you should be seeking thinking and solutions. Only after the ideas have been put forth do you seek to prove their viability.

Step 4. Choose a solution that makes sense

This is where viability comes in. It really comes down to what, why, who, how, when, where, how much and what’s in it for the organization, the benefit, risk and return factor; all the things we learned in grade school and on the playground only with more risk. The best thing is to review situations and possible impacts. Pick three solutions: the do nothing solution, the do something solution or the do something else solution. Think through the issues and make a decision.

Step 5. Implement the solution

It’s not always easy, but it must be done. As the business leader, make sure you have your team together. Establish your approach to deal with people and team dynamics across the organization. Change means push back so be prepared. Be honest about your resource abilities. Invest in their success through investing in your own development. Use a good business coach to avoid future issues. Make it part of the process so your people will embrace it. This is a preemptive approach for solution implementation. Remember, as the leader you do not need to be the sage on stage but be the guide on the side.

Step 6. Measure the results

Ensure that you have put the right items in place to measure the results. This could be at many levels. Answer the simple question: does it work? The answer needs to be a yes or no, not maybe or sort of, eh! Did you get what you expected? How long did it take? Is it over or under budget? Will you see the expected return on investment? If so, over how many years?

Do we have the right people? Have you considered the impact zones and the impact? Does the solution (process, tools, people, etc) align with what is important to the business? The list of questions here is long and depends on what was set as the measurement needs earlier in the planning process.

Step 7. Capture lessons learned

This is an area that business leaders rarely engage in. Yet, it is extremely valuable at all levels in the business. A feedback loop should always exist and the business leader should explore what was learned internally and externally. This is your intellectual property that can be used for future planning and continuous improvement.

In the end, it comes down to following a planning and implementation approach that ties strategy and tactical solutions together. As the business leader your success depends on following a proven approach, engaging your people in the process and building key business skills. Planning for measurable results happens from the ‘get go’.

Don’t forget to leave your comments below.

Behind Every Successful Business Analyst

Is a Business Analyst’s best friend a Project Manager, a Software Developer, a Delivery Manager, a Change Manager, an End User or an influential Stakeholder?

For sure they are all very important associations for any Business Analyst to nurture when working on a project team, but time and again in such environments where new business technical solutions are being formulated, there is an even more important friend to be had for a Business Analyst. A Business Analyst’s best friend is someone who can pave the way to ensure that the technical solution being developed from analysis seals the all-important perception of success.

I’ve written previously on the importance of the perception of success for any piece of work that a Business Analyst undertakes.

The perception of success is where a solution is accepted and readily used by those who it is intended for. It sounds pretty basic stuff, but is too often not fully understood. While the analysis in all its glory and execution may be considered best of breed – even innovative and/or ground breaking or the candidate for a new benchmark for future case studies, if the recipients of the solution think they got a dog, then the work carried out does not have the perception of being successful at all by those using the solution.

Clearly this is not a good situation to be in.

In speaking with a CEO recently, he commented to me that he did not think there were so many good Business Analysts around, and because there were so many terrible Business Analysts, it was a real joy to find a good one. As a Business Analyst myself that’s always a topical one to dodge, especially since I thought he was talking about me!

He said he wasn’t, but did comment that when he used a good Business Analyst, it made his work all the more easy. His bug bear it turned out was twofold. One, it was around lack of clarity in the work coming from the analysts that were then open to interpretation and inadvertently fuelling undesirable outcomes, where the downstream impact was that key targets were missed altogether. Two, this tended to occur because Subject Matter Experts are not Business Analysts even though they might work under the role/job title.

Add in developers who want to put their spin on the resulting functionality and suddenly there was a toxic sludge being mixed and it all too often meant that technical solutions needed serious remedy and re-work.

I suggested to him that a good Business Analysis (and I’m being specific here in that I’m not including a Subject Matter Expert thinking they are a Business Analyst) would have the awareness to engage with his or her most valuable ally on any new technical solution on the day after they start eliciting user requirements for the solution. They would do so because they know how to avoid the problems he had articulated, but also to stock up the right resources at the beginning to ensure that the perception of success would be attained once the dust had settled.

I think the CEO might have tried to hug me at that point. I settled for a second beer instead.

So the big revelation of course was that we were talking about the Business Analyst’s best buddie who is of course the Tester; and how they ought to be working together from the beginning of the analysis phase.

Okay, so that’s probably a bit of a letdown for some, if the truth be known, because readers are probably thinking, of course you’d do that, right?

Right. And any numbers of text books that I have read over the last 20 years or so all said the same thing; engage with Testers at the onset of analysis. Yet all too often, there is no upfront engagement or awareness given to the importance of testing analysis as early as possible at all.

It is fair to say that not all project teams carry a test resource when they kick off, and sometimes the Business Analyst is expected to do the testing as well as the analysis, where budget and money constraints prevent securing a dedicated resource. This is not a situation that I endorse, but it is not a perfect world.

Still the dirty reality should not prevent a Business Analyst from being able to understand who will be the consumers of their work, and what it will be used for. Naturally there are multiple recipients, from Sponsors, Stakeholders, Subject Matter Experts, Developers and, of course, Testers to only underscore the value of the analysis work, and how it needs to be put together to satisfy a diverse range of interested parties.

Where there is no Tester on board, a Business Analyst needs to pretend there is one (yup, just like creating an imaginary friend, as crazy as that might sound) and take the time to understand what a Tester would look for to test and measure against.

Testers, like Business Analysts, have tool boxes of resources that any Business Analyst should have an awareness of whether a Tester is on board or not.

A Business Analyst needs to proactively ensure their work can be tested without ambiguity and needs to ensure that desired outcomes are clearly declared and are measurable.

There are simple things can be incorporated into analysis that don’t take up a lot of extra time to connect analysis with testing with or without the tester on board. The value in doing it is to reach agreement on what outcomes are going to look like. The value in doing this is obvious, specifically because agreeing what outcomes look like early can be carried forward earlier into the all important useability testing with users for acceptance (setting early expectations) for pre-trialling. Hopefully in doing this the likelihood of the perception of success is optimised.

I’ve witnessed first-hand what happens when a Business Analyst and a Developer both chose to ignore the input of their Tester, who in this case was engaged right at the beginning of a project.

Not only did neither recognise the opportunity afforded them in having the tester onboard early, they both saw fit to deliberately belittle the Tester by rejecting their review and/or contribution into their respective work.

The outcome was savage. There was only ever going to be one ‘winner’ given the confrontation that developed, and who ultimately had the power of veto, which neither the Business Analyst or Developer had figured out.

For his part, the Developer simply snubbed the Tester and would not talk with him. The result was predictable. Their code was rejected as it failed to work in accordance with the stated outcomes desired, and had to be re-written.

As for the Business Analyst who prided himself in getting through the work without issue (who proactively engaged with, and actively listened to, stakeholders, and who empathised with users, and carried a solid understanding of the business needs) decided to ignore the review and contributions of the Tester as well and failed to incorporate any of their input into their analysis.

The rationale for ignoring the Tester I believe was that the Business Analyst thought they knew the business and therefore was not going to be told by a Tester to amend their work.

Trouble is (and to their utter amazement) the Tester did not sign-off their deliverables as being able to be tested. The requirements were not measurable, they lacked clarity and were without clear target outcomes; and so it went on. The upshot was that the analysis, without being traceable from end to end on what was a large and complex solution, had to be re-written to better provide what Testers needed to do their work, and to support promises made in the business case which otherwise were unable to be validated or verified.

Both the Developer and Business Analyst were seen to have ‘failed’. The code was wrong, and the deliverables were late. Had the Developer and Business Analyst worked pro-actively with their Tester, and reached a meeting of the minds as early as possible, so much waste (i.e. overspend and longer timeframe) would have been avoided and the deliverables would have included missing content valuable to ensuring the solution would provide what was being asked for.

So while Business Analysts may be the pivot in a Project Team, and nurture plenty of allies around them, it is the Tester who is a Business Analyst’s best friend. They go hand in hand – joined at the hip – so be involved with the Tester (or your imaginary Tester in the absence of a real one) as early as possible, and incorporate what they need without prejudice.

Embrace their knowledge and their expertise into your work and the quality of your analysis deliverables and the resultant business solutions will improve through the roof.

In my mind, the Tester has always been a Business Analyst’s best friend. Snuggle up to them where you can.

Don’t forget to leave your comments below.

Demonstrate Your Value

In 2013, I received many questions about how business analysts can demonstrate the value they add to their organization. I’ve also seen an increased interest in performance measurement for BAs. These two topics are tightly connected, as we are going to see in this article.

The inability to demonstrate the value BAs add to their projects limits what analysts can achieve in their organizations and reduces the opportunities they get to continue to develop their skills. Many BAs find it hard to convince management that they should be involved earlier in business and IT initiatives, so they can help influence direction and reduce risks associated with project scope. Some experience obstacles to even being involved at all in certain projects, which forge ahead without the benefit of a skilled BA to ensure the right problem is being addressed and the right solution is being built. Laura Brandenburg, in this article, mentions another challenge: the lack of funding for professional development, in the form of training, access to conferences and other high-cost learning opportunities.

All these problems share a common root cause: lack of concrete evidence of the value a skilled business analyst brings to organizational initiatives. For example, if you join a company that previously only hired weak BAs who never contributed substantially to the outcomes of software projects, stakeholders might forget to invite you to the discussions during the early phases of your projects. They may also decide to talk directly to developers to define the solution without seeking your contributions, and deny your requests for training, certification, or conference attendance, because they don’t see the potential return on that investment.

But BAs have a powerful tool on their side to help influence management to elevate their role and increase their exposure to enterprise analysis, high-profile projects, and professional development opportunities: performance measurement.

Even if your company doesn’t measure the performance of individual BAs, or does it poorly (measuring things that aren’t directly related to value creation, such as time spent by BAs on each task, number of requirements, requirements volatility), you can establish your own effective performance measurement system. Then, with the performance data collected, you’ll be able to provide solid evidence of the value you bring to your projects and demonstrate the benefits that further investments in your skill development can bring to your organization.

Here’s an example, drawn from my own experience:

Several years ago, I was asked to return to one my clients, a financial institution, to help bring one of their software projects back on track. In the course of the new project, I happened to find, lying on a shelf, a copy of the requirements document I had produced for my previous project. At the time the document was approved, the business stakeholders had offered high praise for my work, but when I opened that copy of the document, I saw many questions from the development team, hired only after I had left for another assignment.

For instance, while the business stakeholders had been satisfied with my requirements describing the “happy path” of a wire transfer being successfully completed, the development and testing teams also needed to know what should happen when an attempt by a customer to submit a wire transfer failed. The expected behavior could be anything from just presenting an error message to the user, to sending an alert to the appropriate account manager so he could immediately follow up with the customer to fix the issue. The right solution could not be built until the desired behavior was clarified.

That experience opened my eyes to an important aspect of my performance that I had been overlooking: writing requirements that not only the business stakeholders found to be in excellent shape, but also the development and testing teams considered to have enough information for them to be able to to build and test the right solution. Providing incomplete or vague information to development and testing teams may cause unnecessary delays when the teams have to list the questions they have and wait for someone to analyze these questions and provide a suitable answer. For that reason, when I saw that annotated document full of questions, I decided to start monitoring my performance in this area.

One of my professional goals became: “reduce the number of questions my requirements documents elicit from development and testing teams”. I defined a target of no more than 3 questions per document for year one and 1 question per document for year two. (This would give me some time to identify the patterns that caused developers to need clarification of my requirements and fix the issues before I started to hold myself to a higher standard.)

With my new goal in mind, I started thinking about requirements not just from the perspective of the business stakeholders (who already were very satisfied with the quality of my work), but also from the perspective of developers and testers. After writing each section of a requirements document, I’d ask myself: “If I were writing the code for this capability myself, would there be something else I needed to know?” And, “If I were in charge of testing this set of requirements, would I know the expected results for all relevant test scenarios, such as entering an out-of-range number, or skipping a required field?” These questions helped me find the omissions in my documents before they were released, drastically improving the quality of the final products from a perspective of the delivery team.

By the end of year two, I had exceeded my goal, with most projects yielding zero questions from developers. From time to time, I still get questions posted to the wiki page reserved for questions about requirements, but I can always map them to one of the following scenarios, which don’t affect my individual performance:

  1. The question isn’t about requirements (e.g., “How many search results should be displayed in each page?” when the decision about how to display search results had been left for the UX designer, who might even design a solution with “infinite scrolling”, so there isn’t pagination to worry about);
  2. The question has been answered in the document already (e.g., “Do we need to worry about different levels of permission for different user roles?” when the Table of Contents of the wiki space that stores the requirements already has a section titled “User Roles”);
  3. The question is about a gap in requirements that is known and noted in the appropriate section of the requirements document (e.g., “Pending definition of which file formats the import capability will have to support”).

Now, how can this approach of setting goals and measuring your performance help you demonstrate your value to the organization and justify more investments in your professional development? Here are some steps that you can follow:

  1. Show the results of your performance measurement and improvement efforts to management, accompanied by an analysis of the impact these results have in project outcomes. Example:
    “Because our development team is in India, each question raised by a developer may cause a delay of up to 24 hours in completing a portion of the code, due to time zone differences. Clear requirements that eliminate the need to ask questions and wait for the answers mean more productivity for the developers working on the implementation of new capabilities.”
  2. Describe the goals you are pursuing next, accompanied by what value reaching this goal will add to the overall performance. Example:
    “My goal for Q1-2014 is to become fully knowledgeable on the business aspects of creating and maintaining promotional discounts for our webstore. This knowledge will help me better understand the business and user scenarios our tools must support, so I can propose better solutions and avoid the change requests that we keep receiving at the end of each development cycle to accommodate missing functionality.”
  3. Ask for whatever resources you need to reach your goals. Examples:
    “In order to help me achieve this goal, I’d like to ask permission to start spending 20% of my time in the marketing department, so I can observe their work when they are creating and updating promotions.”
    “There’s a conference coming up about new trends in web analytics that I’d like to attend so I can bring some new ideas to the marketing team about how they can better track the results of their promotions. Based on better analytical data, I can help the business stakeholders prioritize future enhancements to our promotions engine to reduce the backlog of our projects by cutting scope that isn’t going to contribute to the bottom line.”

The main pitfall to avoid when discussing the value you bring to your organization is what many professionals do in their resumes and cover letters: talk about alleged personal traits (e.g., “I solve puzzles and fix problems better than most”, “I’m good at taking complex ideas and making them digestible”). You want your discussion about value to focus on clear and objective data that highlight recent accomplishments and show the benefits that your current performance and future improvement efforts can bring to the organization.

If you are a business analyst working on the IT space, you’ll probably be looking for evidence of how your work improves the quality of requirements artifacts, lowers the number of defects and change requests, increases user adoption rates, and/or saves time and money by helping the business focus on high-value features. For a process improvement BA, good measures would provide evidence of the return on investment of your recommendations on quality improvement and process modernization, the number of problems affecting customers or employees that have been fixed by your change proposals, and so on.

With a list of accomplishments backed by objective measures, you’ll be able to offer concrete evidence of the value you bring to your team and develop solid arguments to convince decision-makers to elevate your role and give you access to better information and training resources.

Don’t forget to leave your comments below.