Skip to main content

Tag: Team

User Stories – Large Misconceptions. Part 2.

Written by Robert Galen on . Posted in Articles.

In my last post I discussed two misconceptions related to user stories. First was the notion that user stories are static artifacts and the second was that they stand-alone in representing the nuance of requirements. Both of these views are false. In this month’s post, I want to wrap up with two more misconceptions. One is that only a customer surrogate or product owner can write them. The other is underestimating the power of the acceptance tests as a clarifying vehicle for the story.

Anyone on the Team Can (and Should) Create and Update User Stories!

I’ve seen the position of “only the product wner can write stories” taken time after time when I’m coaching agile teams. I’ll enter a Sprint Planning session and we’ll look at the Product Backlog. The team will complain about the backlog not being detailed enough or containing the ‘right’ set of stories. We’ll spend literally hours reviewing them and debating their intent until we run out of time in our time-box and need to reschedule the planning session.

Inevitably these teams point to the Product Owner as being the problem-complaining that they were not prepared.

As an agile coach I always challenge the entire team in these situations. It’s every team member’s responsibility and privilege to write and refine the stories on their product backlog. You see, user stories don’t simply capture ‘requirements’. Instead, they capture all work (let me repeat that) all work that will be undertaken by the team in order to meet the business’s expectations for the project.

Given this, it’s no wonder the product owner (or BA) can’t fill in a complete set of stories. Nor do they have the functional expertise that the team has in areas of software analysis and design, or development, or testing, or converging a product for customer use.

The user stories must be truly owned by the entire agile team. Sure, the product owner will probably spend significant time writing, refining, and ordering them. But consider that to be simply a “seeding pattern”. The stories aren’t truly complete until the team has iteratively refined them together. In Scrum and oft used term for this is – Grooming the Backlog. This is where the team gathers, either as a group or individually, and refines the stories encompassing the backlog.

Underestimating the Power of Acceptance Tests

Much of the focus of writing user stories is on the story-side or behavior-side of the card. Often there is little to no investment in developing acceptance tests (Confirmations) that are placed on the back of the card.

Why is that? My view is that defining test cases is hard for most teams to grasp. It’s sort of an afterthought and not everyone gets the intent or power of acceptance tests. I consider them more important than the user story description, and here are some helpful ways to view them:

  • Consider them mini-UAT tests at a story or feature level
  • They confirm Sprint Done-Ness from the perspective of the customer and the tester
  • They enable testers and BAs on the team to quantify key conditions that the software must meet
  • They drive the design and capability of the software; consider them defining the business logic for a story
  • They are a collaboration driver between developer(s), tester(s), BA(s), and product owner
  • They are either working or not; there is no in-between

There’s quite a bit of debate surrounding how many acceptance tests should be defined for each story. Certainly, they are not intended to exhaustively test the story-so they are not a complete list of test cases. I usually recommend somewhere between three and seven acceptance tests per story as determined by the team. One or two is certainly too few, and 25 clearly too many.

There is also debate surrounding how to phrase the acceptance tests. I’ve seen the following patterns for them across teams’ I’ve been coaching:

  • Verify that…”some behavior”
  • Confirm that…”again some behavior”
  • If I do this…this results
  • Under these preconditions, confirm that…”some behavior”

What’s important here, truly important, is not the phrasing, but that you define and confirm acceptance tests on a story by story basis. It drives quality collaboration and quality results within your agile teams.

Wrapping up – I hope I’ve clarified these four misconceptions and ultimately improved your user story writing.

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

The Business Analyst’s Requirements Meeting from Hell!

Written by Dana Brownlee on . Posted in Articles. 3 Comments on The Business Analyst’s Requirements Meeting from Hell!

Secrets to Managing the Difficult Personalities in Your Meetings

Business Analyst Sherry Martin couldn’t stop thinking about her last team meeting as she walked down the hall towards her office. She’s leading a team charged with developing a requirements document for a hot new IT product, and things have not been going well. Slamming her office door behind her, she let out an exasperated scream and looked for something to punch! Her team was driving her absolutely crazy and she channeled Scarlett O’Hara as she proclaimed, “I will never run a meeting like that again!” Her problem in a nutshell boiled down to three really difficult personalities that continually recurred on her team. These personalities were indeed a cancer, not just infecting the team and its results but also spreading throughout the group and infecting individual team members as well.

Sherry needs an antidote… now!

Here’s a little help for Sherry…and for you! Let’s explore these common dysfunctional personalities and take a look at how to effectively manage them.

The Dominator

We’ve all experienced “the dominator” in one way or another. Some people tend to dominate discussion simply because they’re excited and over zealous. These can actually be valuable members of the team if we can find appropriate approaches to harness and manage all that positive energy. Unfortunately, most of us are more familiar with the other type of dominator – the overly aggressive, bullying personality that tramples on others’ comments and may attempt to hijack the meeting completely! Sometimes, these dominators are overly negative (“That’ll never work here!”), and other times they just won’t let anyone else get a word in edgewise. In either case, dominators can certainly sour not just the effectiveness of the meeting but also the morale of the team.

Techniques for Effectively Managing the Dominator

  • Thank the dominator for the feedback and ask for others’ input (e.g. “Steven, that’s an interesting idea. Let’s see if others have suggestions as well.”)
  • Reiterate the dominator’s comment, write it visibly for all to see, and then ask for other ideas to complete the list. (e.g. “Steven, it sounds like you’re recommending that we use these three vendors as our short list…is that correct? That’s a great suggestion. Let’s compile a list of several suggestions, then discuss them all. We’ll list your suggestion as “A” on the list. I’d like to get at least three other suggestions from the team. What do others think?”)
  • Instead of having the group respond to an issue verbally, ask them to take 2 minutes to jot down their idea, issue, or recommendations on a post it instead. Then ask each person to share one comment they wrote.
  • Suggest the group use the round robin technique (go around the room asking each person to share a comment) and start at the opposite end of the table from the dominator (e.g. “This is such an important issue that I want to be sure I’m getting everyone’s ideas. Let’s do a quick round robin starting with Jill…”)
  • Call on a few people you haven’t heard from (e.g. “Michael, what are your thoughts on this issue?”)
  • Take a break and solicit the dominator’s support offline (“Steven, you’ve brought up several key points. I’m hoping to get some of the other team members involved in the discussion to hear their ideas as well. Some members of the group are not as assertive, but I want to be sure we hear from them.”)
  • Break the group into pairs or triads and let them discuss an issue in those smaller groups before initiating a large group discussion
  • Gain agreement with your team to use a physical object (e.g. sponge football) to balance discussion. The person holding the football has the floor, and they must toss it to someone else once they make their point.

The Multi-Tasker

Increasingly, we’re seeing more and more multi-taskers in our meetings. Aptly named, they’re the ones whose attention constantly darts between the meeting leader and any number of other tantalizing distractions (e.g. PDA, laptop, reading material, etc.). Indeed, the multi-tasker is physically present but mentally elsewhere.

Techniques for Effectively Managing the Multi-Tasker

Bring the issue up to the group during first few meetings and decide as a group how you want to handle the technology distractions…options may include

  • Using a “technology drop box” at the front of the meeting room and agreeing to drop it in prior to meeting start
  • Limiting meeting time to one hour to ensure participants aren’t away for too long
  • Agreeing on 15 minute technology breaks every hour
  • Participants bring a buddy to “cover” for them in case they have to step out for a call

Use facilitation techniques that keep participants actively engaged

  • Round robin
  • Active questioning
  • Affinity diagramming
  • Sub team work
  • Dot voting
  • Use a circular or U shape room setup that allows you to easily walk around (and near) various participants quite easily
  • Agree upon a mild punishment for texting, emailing, etc. during the meeting. One group used a PDA jar and violators had to put in $5 per violation. (Money was later used for team lunches)

The Rambler

The rambler can seriously derail a meeting with their circuitous, protracted, rambling commentary. Oftentimes, the rambling strays into areas bearing little resemblance to the topic at hand. The rambler can not only significantly extend the length of a meeting but also completely alter the meeting content, thereby minimizing the team’s efficiency and effectiveness.

Techniques for Effectively Managing the Rambler

  • Have a printed agenda (on a flip chart or whiteboard) in the room. When conversation strays off topic, stand up and point to the specific agenda topic to refocus the group.
  • Include timings for each section of the agenda so you can more easily focus the group on the time allotted for each discussion point. Possibly ask someone on the team to provide a five minute warning before the scheduled end time for each section of the agenda.
  • Simply raise your hand and interrupt discussion to ask if the conversation is on topic and helping the group reach their goal for the meeting. (“Guys, allow me to step in for a moment to ask whether the vendor discussion is relevant for this particular section of the agenda?”)
  • Introduce the Parking Lot at the beginning of the meeting and announce that you’ll interrupt discussion to place any off-topic discussion points on the parking lot to help keep the group on track. (“Jill, I realize that you feel strongly about the inventory control issue, but I’m wondering if we should try to resolve that now or could we possibly place it in the parking lot?”) Review all parking lot items at the close of the meeting and assign action items for each.
  • Assign someone on the team to act as the “rambler police” (use a badge if appropriate). This person is responsible for raising their hand anytime the discussion veers off topic.
  • Consider using the ELMO technique. ELMO = “Everybody, Let’s Move On!” Whenever anyone in the group feels the group is rambling too much, they’re expected to pick up the ELMO doll in the center of the table.

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. which operates www.meetinggenie.com, an online resource for meeting facilitation tips and instructional DVDs.

Cultural Intelligence – Do You Have It?

Written by Elizabeth Larson on . Posted in Articles. 2 Comments on Cultural Intelligence – Do You Have It?

There are lots of different types of intelligence. Components can include such things as understanding, learning, use of language, creativity, emotional, and many others. This decade’s intelligence emphasis is cultural. Understanding different cultures is something I’ve always been interested in, but I’m not sure I always exhibited an abundance of cultural intelligence.

Years ago I lived in a South American country, far from my American home. When I first arrived, neighbors brought me welcoming treats ranging from a single mango to elaborate desserts in fancy dishes. After removing the treat, I would wash the plate and return it. Finally someone told me that it was rude to return an empty plate. The custom was to place a return treat on the clean plate. Completely unaware of this custom, I had unintentionally offended my kindly neighbors.

PMs and BAs usually understand that working with team members from different cultures presents unique challenges. Many of us completely oblivious to a particular custom, find that we have inadvertently offended someone on the team. I once managed a project that included several foreign team members working on the software development phase of a large project. I remember reacting with surprise when a team member told me that in her country she kissed her father-in-law’s feet whenever she greeted him. She explained that in her culture this was a sign of respect. This action, which seemed so different from anything I had ever experienced, was the norm for her.

On the same project, another developer rarely completed his assigned tasks on time. When I met with him in a conference room and asked about the missed deadlines, he refused to offer an explanation. During the meeting he appeared uncomfortable, but remained silent. I had mistakenly thought that team members would complete their assigned tasks. It never occurred to me that in some cultures work is completed based on relationships, not simply because the tasks appear on a Gantt chart. I later learned that the conference room meeting had been highly threatening to him, and that he was uncomfortable reporting to a woman.

Culture clashes can occur not just between people of different countries. As a manager I frequently noted what I called the “second company syndrome.” Candidates’ resumes often showed long tenure at the first company worked and a far shorter one at the second. When asked, candidates often said that they couldn’t get used to their new organizations. I heard things like the new organization had “too much process,” or “things were so chaotic,” or “they’re so unfriendly. No one goes out to lunch together,” or “everyone expects me to go out to lunch with them when I really want to eat at my desk and get some work done.”

There are even cultural clashes between business units within the same organization. I’ve worked in organizations where “users” clashed with IT and vice versa. In one organization I heard statements like “I’m surprised the elevator doesn’t automatically stop on the IT floor because of all the polyester worn there.” Or “those dumb users-they don’t know how to define their requirements.” I think it’s important to recognize that there are no “rights” or “wrongs.” Although we tend to view “our way as the right way,” we need to keep in mind that our ethnocentric perspectives can not only cause bad feelings, but can also hinder our ability to get the necessary work accomplished.

So what is ethnocentrism? It’s the “my way is the right way” attitude. It’s applying negative judgment to the way others live, work, and worship. We can recognize ethnocentrism when we hear phrases like, “How weird!” or “How can these people live like that! ” It’s feeling that one’s norms are superior to others.” “At my old company we used to write use cases” implies that writing use cases is the best way to discover and document requirements.” Or, “our systems were implemented almost without defects at my old company.” Or, “on my previous team we used to bring treats on Fridays. I don’t know what’s wrong with this new team-they never seem to want to have any fun.”

Related to ethnocentrism is culture shock, which is what happens to most of us when we live abroad for an extended period of time. The cultural differences become so overwhelming that we can become disoriented and distressed. We can’t wait to return home to what we view as “normal.” I believe that another team member experienced culture shock when she expressed surprise to learn that it is not uncommon for American parents to hug their children. She noted that Americans seemed so cold to her that she couldn’t image them expressing affection to one another.

I find it helpful to remember that new team members (from other countries, regions, organizations, or teams) may experience culture shock to a greater or lesser degree. They may miss their families, the camaraderie of previous teams, the HR policies of a previous company, or the weather, scenery, and customs of their home country. I have had team members experience culture shock on my team, but I didn’t always recognize it. I sometimes made the mistake of taking their distress personally. My tendency was to withdraw, when exactly the opposite was needed. However, I learned that rarely can we go wrong when we go out of our way to build relationships, listen, and offer support when working with team members from other cultures.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected]

Top Five Reasons BAs Need a Central Hub of Product Intelligence

Written by John Simpson on . Posted in Articles.

In the world of product development, and specifically requirements management, you hear a lot about building a “central repository of requirements” or a “single system of record”. But, why does that matter? What problem does that solve? What’s the real value in creating a central hub of product intelligence?

central-hub1

First, let’s define central hub of product intelligence. What are we really talking about? Naturally, we think of the data (aka. artifacts or items) – the ideas, feature requests, requirements, design specifications, analysis documents and reports, release plans, defects, etc. – all the data that explains the scope of the product the team is building. The difference in why we use the word intelligence instead of data is that product intelligence expands beyond the artifacts. It also includes two other important related categories of information that support the social nature of the product development process.

Conversations. There is an ongoing dialogue throughout the product development lifecycle. Customers provide feedback. Analysts capture insights. Teams discuss requirements. Managers communicate decisions. Organizations make commitments. By including the conversations in context to the requirements and other data, your team will have the complete story of what customers need and understand the discussion as to how your team arrived at the requirements you have. The context is huge. Without context, you have higher risk of misinterpretation and defects later on.

Relationships. Often referred to as traceability (the upstream and downstream relationships between requirements and other items), the links between the data and the people who own the data are important for understanding all the dependencies, and creating a dynamic environment where you can intelligently manage and communicate changes when they occur. As a practical example, for developers working on detailed functional requirements, having the visibility to look upstream to the high-level business requirements and original feedback from the customer is huge in providing full context to what they’re on the hook to build.

Why This Matters

There are many reasons, but let’s look at these top five.

  1. Information silos kill productivity – 42% of employees accidentally use the wrong information at least once a week.
  2. Employees and information are fluid – they flow in and out of teams and projects constantly – what info gets lost in transition?
  3. Employees spend 25% of their time just looking for information.
  4. Employees waste 20 minutes or more each day recreating information that already exists.
  5. The total information we’re inundated with grows 66% every year, so this problem will only get bigger over time.

Unproductive Stat of the Day. “It’s estimated that employees at U.S. companies waste over 5 billion unproductive hours annually just looking for information.”
– Searching Kills Employee Productivity Blog

It’s such a simple concept – capture all the relevant product intelligence in one place. Wow, that’s a breakthrough idea, right? The reality is that it’s difficult to eliminate this problem completely; it affects every organization on some level. We’ve worked at start-ups with 10 people in the same office and Fortune 100 companies with 75,000+ employees worldwide, and it exists at both. The question isn’t whether it’s an issue in your company. The more important question is, “What’s the full impact it’s having on your team and their productivity, and could a better solution make a significant difference?”

Solutions range from using back of the napkin/whiteboard to Word/Excel documents to Wikis to specialized requirements management software. You may use them all; we do. The solutions you choose will depend on your organization and the complexity of the products that you’re building. One of the decision criteria to use to gauge whether you need specialized software is to determine what degree your team suffers from the Silo Effect. Borrowing from the infamous Cosmopolitan quiz style, use the list of questions below to determine whether your team is at risk.

Take the Silo Effect Quiz

[Yes] [No] – Do you have duplicated sources of data and multiple versions of requirements spreading across your organization like the Swine flu?

[Yes] [No] – Do you have departments that are disconnected and unaware of what the other is doing? Is the right hand talking to the left hand? Be honest!

[Yes] [No] – Do you operate in an industry with compliance standards, where detailed version history and specific requirements documentation are required for approvals?

[Yes] [No] – Do you spend more than 20% of your time hunting around for the latest product information and requirements specs?

[Yes] [No] – Is visibility into the product development process limited for stakeholders? Hint: if you’ve heard or use the term “black box” in a meeting recently, then mark “yes”.

[Yes] [No] – Do you have communication gaps or blind spots related to customer commitments, feature request or other insights into what your customers need?

[Yes] [No] – Do you have frequent transitions of staff in and out of product teams?

[Yes] [No] – Do your business analysts match the 27 points of compatibility with your engineers? Sorry, ignore this one. We got carried away by the style of these quizzes.

In all seriousness, if you answer “yes” to two or more of the first seven questions above, then it’s probably time to evaluate other options to help you eliminate the silos and bring it all together into a central hub that’s accessible, searchable and reportable.

Productivity Gains from Eliminating the Silo Effect

  • Save time and money that’s wasted searching for information
  • Reduce costly guesswork, rework and related defects
  • Eliminate redundant research and duplicate projects
  • Shorten ramp-up time of new employees to the team
  • Give complete context to the goals and scope to everyone involved
  • Improve the mental well-being and sanity of business analysts (it’s not all about your company. You deserve something out of this too, right?)

Keep in mind, that having a central hub of product intelligence isn’t the end-all-be-all solution for fueling innovation. It’s just one capability in a list of many that are required to successfully plan and build products that work. If you have a broken development process, a central hub won’t solve that. If your team doesn’t have the right skill sets, it won’t fix that either. However, what we’ve found over the years is that of the myriad of challenges we face managing product development, bringing all the relevant product intelligence together in a central hub is one of the immediate and practical steps an organization can achieve right away to speed productivity, reduce costs and improve quality.

Moment of Zen: Sometimes the first step is the most valuable one to take!

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware

John Simpson, Jama Software: [email protected]

User Stories – Large Misconceptions. Part 1.

Written by Robert Galen on . Posted in Articles.

One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.

Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.

User Stories are Organic!

If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.

Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.

As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.

The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.

While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.

User Stories are not a Catch-All Artifact!

The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.

In this case, they’re suggesting supplementing the Story with a known additional artifact form.

This is great!

Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.

The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.

One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.

As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases

Next post, well finish with the other two misconceptions

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].