Skip to main content

Tag: Scrum

It’s the End of the Business Analysis World as We Know It? Part 3

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Blais FeatureArticle June4Chapter 3: Wherein the doomed business analysts are introduced to the Product Owner and Verna makes her entrance

At the lunch table Brian asked Ann why Helen called her to tell her about the impending cut backs.

“I’ve done work with her before. She asked me to collect information on the current projects and talk with the people on the PMO and other management groups to see where the cut backs might occur. It’s kind of an irony. I am going to be reporting back that I don’t have a project to be on. I’ll be basically firing myself.”

“No” reassured Brian. “That’s not going to happen. Listen. We are business analysts. We need to evaluate the information we have, gather the information we don’t have, assess the problem and define a solution. It’s what we do. Except that now we are doing it for ourselves and not some other part of the business.”

“We are a part of the business,” suggested Raj.

‘For now,” grumped Ann.

“Listen, Ann. If you need any help, It looks like we won’t be spending a lot of time in the planning stages of Backbone, so give me a call. In the meantime, I’ll go break the news to Jennifer, Jocelyn and Stan that they will likely be placed on one of the Scrum teams as developers. I don’t know how they will take it.”

“Better than the others who don’t have any team.” Commented Raj.

The next day Ann took Brian up on his offer and asked him to accompany her to talk to Pam one of the business managers who was designated to lead the Backbone effort and Dmitri, one of the senior marketing managers who was in charge of several of the new marketing efforts and web sites. They first met with Pam.

Pam was concerned. She had been told by Ken and her boss that she was to be the Product Owner and she did not really understand what a product owner was supposed to do. She was told that she would have to be available almost full time to the team and that she was responsible for the ‘product backlog’ and to talk to the team about what was on this ‘product backlog’. They told her that her job would be about defining what she wanted in the form of user stories. She was glad that Ann was there. Although Pam was the organization’s authority on internal operations, having worked her way up through the ranks in operations, she had depended on Ann to provide her the technical perspective in terms that Pam understood; Pam had worked in the organization a long time and tended to use the telephone and in person meetings rather than email. Ann called Pam her “favorite troglodyte”. Pam was not enamored of the idea that she would be dealing directly with the technologists.

“I don’t know what to do, Ann.” She looked pensive. She stared out the window of her office at the parking lot. “Frankly I would have wanted you to work with me, because we had already had a good relationship, but…”

“I know,” said Ann to Pam’s back. “Ken and cohorts are insisting on this product owner thing.”

“Oh, those nerds. No, it’s not them. It’s Verna.” The name brought a chill to the room. Verna! None of them had ever seen Verna. Or at least no one talked about having seen Verna. Or at least no one still with the company had seen Verna. Verna was the Vice President of Global Operations and some said that she was really the power behind the CEO. She was Vince’s prime competition for the top position when the current CEO steps down. There was a reverential pause in the room. Ann and Brian both instinctively looked over their shoulders at the doors as though the mere mention of Verna’s name would summon her as the Gods of Ancient Greece were summoned in the temples of Athens. The moment passed. Ann shuddered.

“Verna? Really?”

“Yes,” said Pam dolefully turning back to her desk. “And I don’t know how much time I can devote to writing this product backlog creation and rearranging business or what does Ken call it? ‘Grooming’? I don’t even know what that means. Do I need scissors and a clipper?”

“From what I understand, Pam,” offered Brian, “you need to write user stories that describe the functions and features of the system.”

“All of them? There are nearly four thousand people worldwide using this system for I don’t know how many different functions. There’s purchase ordering where I spent a lot of time, and vendor assessment, and inventory control, and updating the general ledger and, I mean, it’s big. I don’t have time to write these,” she paused considering a number of different pejorative adjectives. “user stories”. She pointed to a stack of blank index cards on her desk. “Ken left me these and told me to just write down all the features I would need on the system. He has got to be kidding. Do you know my schedule over the next weeks alone? I am in meetings in five different cities in four countries to evaluate local vendors. Then I am in meetings onsite for the evaluation of the new purchase order system that we are going to modify. All day meetings. And he wants me to be available to his teams? I’m going to be in Tokyo! That’s twelve hours’ time difference!” She was still standing up, but leaning forward with the palms of her hands flat on the surface of her desk and her voice rising. “Does he want me working twenty four hours a day so I can be available to his team whenever they have their stupid questions? If it weren’t for Verna…” She paused and sat down. Brian and Ann surreptitiously glanced toward the door. The chill passed. “I don’t know what to do,” whispered Pam to Ann. “If only you were not being replaced as business analysts. You certainly helped me out in the past.”

“I have an idea.” Pam leaned forward. “You know Summer. She worked on several of your previous projects with me. She has also worked in a number of positions in the company before becoming a business analyst: HR, communications, accounting, marketing, and so forth. She also knows the systems. Why don’t you let her take over as your product owner?”

“Can I do that?”

“She’d have to give up being a business analyst.” Brian reminded them.

“That’s all right. I’m sure she is willing. She has had many jobs, including as a manager, so she knows how to manage and handle authority.” Turning to Pan, Ann pressed on. “She certainly can create user stories or whatever is necessary for the product backlog based on her business analyst experience, and she knows enough to be able to clearly express those Product Backlog items, order the items in the Product Backlog to best achieve your goals and missions. Since she did a lot of the acceptance testing for several of the systems we have in place, she will also ensure the value of the work the Development Team performs. She also has the facilitation skills that all business analysts possess to ensure the Development Team understands items in the Product Backlog to the level needed.” *

“Sounds perfect.” Pam responded her mood picking up. “She can be the product owner for this initiative and report to me.”

“But she has to have full authority to make decisions on behalf of the product,” cautioned Brian.

“No problem,” assured Pam.

“Well, that was fortuitous,” breathed Ann as she and Brian walked down the carpeted hall from Pam’s office. “We have Summer reassigned now as a product owner.”

“Yes. And I believe Raj can perform the same role for Georgy in Supply Chain.”

“You are right! Quite a few of our business analysts can be Developers or product owners. The role may disappear, but the people won’t.”

“But we need to consider the rest of us. We can’t program and I for one am not in favor of giving up my analysis and facilitation roles to become a management type again. I have already been a project managet.” muttered Brian.

“Me, too.”

“I wonder why Verna in involved with this whole thing?” mused Brian and they both stopped walking and looked in front and behind them. The usual noise level of the corridors of organization headquarters seemed to turn to deathly silence at the mere utterance of the name. The both instinctively checked their phones to see if some ethereal message had appeared. Nothing.

“I don’t know. It’s strange.” Whispered Ann. “She usually doesn’t ‘get involved in things like this. I guess we see Dmitri next. We have to get this information back to Helen soon.”

“Wonderful. The sooner we get the information back to her the sooner we will be out of jobs here at the organization. The irony! Incidentally, do you have your resume dusted off?”

“No. I can’t stand to even think of it.”

“Well, Dmitiri won’t be a fan. He works for Vince and you know where Vince stands, and he and Ken have worked on some of the pilot scrum teams so he is an experienced product owner. Besides, I don’t think he likes business analysts in the middle either.”

As they entered Dmitri’s office, they heard him hanging up the phone. “Yes, Verna. I understand. They are here now.”

Will Dmitiri be the death knell for Brian and Ann and the other business analysts? Will they drown under the wave of the Agile New Order? Will Brian and Ann stop looking around every time Verna’s name is mentioned? Who is Verna anyway? Tune in next time when we hear Dmitri say, “It’s curtains, Brian.”, and Brian say, “We are doomed.”.

Don’t forget to leave your comments below.

* Adapted from Schwaber & Sutherland, “The Scrum Guide, the Definitive Guide to Scrum: the Rules of the Game”, published by Scrum.org, July 2011

Is the Product Owner part of the Team?

galen May27 ArticleAs a Certified Scrum Coach (CSC), I belong to a CSC/Certified Scrum Trainer discussion group. The folks on this list are a relatively small group of coaches and trainers that are one of the driving forces behind Scrum.

They are thought leaders, evangelists, and practitioners. It’s an incredible group and I’m humbled to be a part of it.

As you can imagine, there’s always discussion and debate going on about the nuances of Scrum, Agile, and the associated practices. Sometimes it gets quite heated. I won’t share the specifics, but I do want to focus in on a thread that seems to come up quite often. The question:

Is the Product Owner a part of the Scrum Team?

It sounds like a simple question, one with a clear answer. However, it seems that it causes a nearly 50/50 rift in the above community. Now to be fair, the entire community doesn’t always “weigh-in”, so it’s hard to get an accurate assessment. But it certainly feels like a 50/50 split. And I find it somewhat confusing that such a small, but important point can have such ambiguity.

Before I weigh-in with my own opinions, I’d like to gather a few from well-respected resources.

A Few Opinions

From the Agile Atlas, I captured the following:

Scrum is a team process. The Scrum Team includes three roles, the Product Owner, the ScrumMaster, and the members of the Development Team. The Product Owner has responsibility for deciding what work will be done. The ScrumMaster acts as a servant leader, helping the team and the organization make the best use of Scrum. The Development Team builds the product incrementally, in a series of short time periods called Sprints. A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals. In each Sprint the Scrum Team will build and deliver a Product Increment. Each increment is a recognizable, visibly improved, operating subset of the product, meeting understood acceptance criteria and built to a level of quality called the Definition of Done.

And from the Scrum Guide , the following surrounds the definition of the Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

In both cases, the distinction is for the Product Owner role to part of the overall Scrum Team. I didn’t say the “Development Team”, but the overall Scrum Team.

So, Why Exclude Them?

In the discussions I’ve seen surrounding whether the Product Owner is on the team have circled the following four major points:

  • They’re not part of the team, so they don’t talk at the daily stand-up. 
  • They can’t attend the teams retrospective. This is one point that gets the most traction. The logic goes that they can skew the discussions in the retrospective to be too business-centric or results focused. Rather than internally towards the teams’ improvement.
  • They’re too busy to engage with the team as a “team member”.
  • Their role is simply too different; that is they don’t contribute work to the sprint.

All of them concern me, but the second point most of all.

I clearly ‘get’ that the Product Owner role is separate from the Development Team in Scrum. I think that distinction is healthy and balanced. However, I don’t think the Product Owner (nor the Scrum Master) should be excluded from participating in any of the teams Scrum ceremonies or activities. Nor should they be precluded from speaking.

From my perspective, they’re a member of the team with equal footing in all areas as long as we support the inherent fundamentals of each role – role and responsibilities.

Why do I want the Product Owner ‘in’ the team?

So you might be asking, why do I feel so strongly about this point? It originates with the notion of agile being a “team sport” and the self-directed team aspects of creating high-performance teams. I think ‘teaming’ is a central component of the success potential. Here’s a short-list of reasons why I want the Product Owner to be “on the team”:

  • So they have some skin in the game
  • So they’re accountable for the teams’ success or failure
  • So they learn with the team
  • So they begin to understand the teams’ strengths and weaknesses (including their own)
  • So they attend ALL of the ceremonies and fully engage (as all team members should)
  • So they make themselves “available” for the team when they are needed
  • So they try to “sit with” the team
  • So they occasionally try and do some work within their team, for example, feature testing
  • So they invest in continuous team improvement; which includes: sharing the competitive/business landscape with their team – domain knowledge
  • So they celebrate success with the team

And I don’t intend this list to be exhaustive; as I’m sure I missed things. But surely you get a sense for the ‘why’ behind my concern and argument.

Wrapping Up

Can a Product Owner become too involved in the development process and create churn? Perhaps. Can they share business pressure with the team and push them to deliver too quickly? Sure. Can they become separated from the team due to job time constraints and appear to be disinterested? Absolutely.

Can the Scrum Master operate poorly? Can the Development Team operate poorly? A clear yes to both. But excluding them from the team is only one possible ‘solution’ for these challenges. I’d rather look at root cause and fix them than exclude folks from the team who are creating ‘churn’ or are operating poorly within their roles. But that’s just me.

Like I said, approximately 50% of the CST’s seem to want the Product Owner outside of the team. So, you’re not necessarily wrong if this is your model or posture. 

However, I’ve just got a different view. AND, in my agile experience this model has always led to better results. When I refer to a “Scrum Team”, I personally like them to be “composed of”: a Scrum Master, a Product Owner, and a cross-functional team of “developers” who are sufficiently skilled to deliver on their Product Backlog and meet their Definition of Done. This to me is a TEAM, and anything that undermines that notion is something that creates a lesser result.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Frayed Agile Pools – The Ultimate Methodology At Last

Ferrer May21 ArticleVision-Schmision is Taking a Break

To bring you this breaking news!

V-S vill be bock!

A new paradigm has emerged, and just as some (the fools!), were starting to think that Agile might be a fad after all, fading just like April showers of the recent past. As team after team has struggled with the productivity gain potential (stress!) of more teamwork and less messing around, many have found Agile wanting.

Scrum is often used as a scapegoat, as in statements such as: “They used Scrum rituals but did not practice agile” and “They are Pond Scrum.” Scrum is a simple set of rules and calculations that anyone could follow, and they do. Scrum is easy.

Concerned Agilists* protest that true implementation of Agile is hard, and that Scrum is not Agile. Some say that agile teams that fail must not have practiced Agile at all, since Agile cannot fail by definition. Enlightened management sees this as a critical error. As Edward Deming said: ***

When you think of all the underuse, abuse, and misuse of the people of this country (US), this may be the world’s most underdeveloped nation.”

It seems that blaming people**** is not the way to “fix” Agile. If, as Deming claimed, it is the “system” in which we work that accounts for most behavior. If Agile is our “system”,  Then Agile itself must be at fault! *****

The good news is that the Agile Control Group******* has done a root cause analysis, and has just done a press release******** announcing the solution to any Agile “blues”. They have figured out that it is possible to create multiple Agile teams capable of handling ANY project in ANY timeframe, however short.

For example, one of the Agile principles is:

“Agile processes promote sustainable development. 
The sponsors, developers, and users should be able 
to maintain a constant pace indefinitely.”

Root cause analysis shows that employees are underperforming against management’s expectations almost everywhere these days. Many employees will , and will pad their task estimates so they can web surf and tweet on employer time. The “constant pace” principle is SO tempting that employees will set a pace lower than a boss has a right to expect, especially if the employees are experts (IT) and the boss is not (Product Owner). Frayed Agile Pools can address this issue in the following ways:

By splitting a large project into smaller (fractal) pieces (fraying). This allows a boss to make ANY deadline with no whining. Let’s say that your worst Agile team can produce 100 lines of code a day. If success is achieved by producing 1000 lines of code a day Then the boss can succeed by creating 9 more Agile teams (the “pools”) and merging their code every day. This has the advantage of increasing the number of “product owners”, each with the correct expertise to support each team in the pool.

This “fraying” fractal process eliminates all excuses, is “free” in the sense that the cost per line of code need not rise (bring in or outsource contractors), and cannot fail to produce more code. If productivity suddenly drops below 1000 lines per day, the boss will KNOW whom to motivate. Knowing whom to motivate is a management “key success factor”.

Because of the brilliance of self-commitment, the coders must achieve their own “estimates”; else they will look weak to the team. In this kind of “self-organizing” productivity environment, management can slowly increase pressure, by insisting on increased code production as Agile succeeds where the team could not succeed before. If the team protests, remind them that Agile says:

“At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly.”

This may “fray” some nerves, but you can tell the teams that it is more fun to be busy, and that stress is what coffee and donuts are for. Forgetting donuts is one mistake where it is OK to blame management.

Another Agile principle is:

“Business people and developers must work together daily throughout the project.”

Root cause analysis for this principle is, of course, trivial. No businessperson has time to work on projects, and most are too old or overweight to sprint. They are too busy fixing what is failing, even though what is failing is also the driver for the project you are asking them about. They are too busy sawing to sharpen their saws. They have meetings to plan how to plan other meetings. They installed Quicken on their home PC, and can’t understand why you can’t get SAP (or Oracle, or PeopleSoft) up and running without infuriating other business people. They can’t take their fingers out of the dam just to talk with a hydrological engineer – the dam could collapse, and besides, fixing the dam is not the business’ problem. 

Frayed Agile Pools offer some ways to fix this “broken Agile” problem.

Reassure the business people by letting them know that the dam WILL collapse, but not to worry as there are MANY pools of developers to absorb the flow, and no businessperson will need to be washed away.

Reassure the developers by pointing out that every pool will have access to whatever time is available from business people, so that all pools are on a level playing field. By spreading stakeholder time across multiple pools the business’ knowledge goes further.

Encourage the multiple product owners to ask for more complicated solutions, since they have so little time to spend with the developers. Since we are able to produce as much code as needed without increasing the cost per line of code, this will maximize our delivery of working software.

One could go on an analyze root cause issues with other Agile principles, but we end by mentioning one principle that is honored by every Agile team I have witnessed: 

“Simplicity–the art of maximizing the amount of work not done–is essential.”

The simplest teams are always the best – with practice, and judicious application of inhibitors; a top-notch simple Agile team might not ever break anything, ever again 🙂

For other BA Times articles on Agile and how it affects project outcomes, try these links:

Pursuit of this breakthrough might even lead to the holy grail of project management, the plan they shoot for (aim, ready 🙂 many times:

Requirements For Nothing and Tests For Free.

Have fun, and don’t forget to peer review with your comments!

* What else takes a 3 day class to get certified for a $115K** job?
** Prices set by the state of Virginia unemployment job service 🙂

*** Deming finishes with: “It’s about time for American management to wake up.”
**** Management are not people, Deming believed most were short sighted.
***** Logically, IF the first part is false  THEN the whole statement is true. ******

****** This is different from the truth of the second statement – fun lookup! 🙂

******* They are coming to get you, woooooo…. 🙂

******** If the press release still exists 🙂 Then you will find it here.

It’s the End of the Business Analysis World as We Know It Part 2

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Blais FeatureArticle May14Chapter 2: Wherein the doomed business analysts figure out a plan to embrace change

When we last left Brian Allen he was facing the Perils of Pauline the head of the organization’s PMO. 

Brian was worried, not just for himself and Ann, but for the other business analysts in the group. There were the senior business analysts, Stan, Shelly and Summer. And there were the junior business analysts: Jennifer, Jocelyn, and Juan. What would become of them if all the business analysts were eliminated from the software development process? The other business analysts worked on other projects not currently threatened by Ken and the Agile Forces. But they soon would be, especially if Ken’s project were successful. Brian turned his attention to Pauline who sat framed in her office window with the sunlight bouncing off her black curls.

“I have gotten the word not to assign a project manager to the new Backbone Project. They are going to be using this agile thing to develop the software and manage the project. Do you know anything about it?” Pauline asked with her eyebrows arched. She spoke through compressed lips.

“Yes,” Brian replied. “I was aware it was coming down the pike, but thought that cooler heads would prevail and we might start with a small project first. Maybe a new label printing project or something equally benign.”

“Well, it is happening and as you are probably aware, that also means that the PMO will not be assigning any business analysts either.”

“You never assigned business analysts before.”

“That is irrelevant. We will not be doing it now.”

“I suppose those of us originally assigned to the Backbone project will have to be reassigned to other projects now?”

“That would normally be the situation. However, most of the new projects are in Marketing, and the Vice President has decreed that all his projects from now on will be run as agile projects. There is no place for business analysts there either.”

“In other words…?”

“In other words, there are no projects for you to go to that are not agile right now.”

Brian looked down between his feet. “Any idea of what we can do?”

“Not in the least,” snipped Pauline. “I have my own problems. I need to figure out what happens to the PMO and my job when there are no project managers and software developers start working directly with the business owners.” She was being dismissive.

Brian got up to leave wondering why Pauline called the meeting. As he reached the door he realized that she was actually asking for his help, but would not do so directly. “I’ll see what I can do, Pauline,” he said as he left noting that she smiled for the first time. He guessed that she was coming to him since he was instrumental in evolving the processes that developed into the first PMO at the organization.

As he walked down the hall he passed Ann who was with Raj on their way to talk to Pauline.

“Any luck?” asked Ann apprehensively.

“No. But we’re not fired immediately. Basically, we have to figure out how we will fit within the New Order,” replied Brian.

“Not a good proposition,” said Raj. “I perceive we are up against the wall on this. Ken does not like business analysts and I doubt he ever has, although I only know the man for a few years. He thinks they add no value to the process of developing software. He says that they get in the way; they are an obstacle. He says that business analysts only copy down what the business people tell them as requirements and then reformat them and give them to his developers.”

“We do more than that!” said Brian emphatically. Then after pausing and getting no supporting reaction from either Ann or Raj, added, ‘Don’t we?”

“Well,” said Raj. “I have to recall that his comrade, Scott, says that ‘BA’ also stands for ‘Band Aid’. I would not take that as a positive sign.”

As if on cue, Ken and Scott rounded the corner and came upon the three business analysts. Ken was tall with short cropped blonde hair and a stubbly beard on his face, and Scott had long, dark-haired, was shorter and rounder, and wore sliver glasses that were rectangular shaped.

“It’s the requirements gatherers,” Ken said with a sneer. “Hello, Gatherers, let the hunters through. We have projects to do. We’ll get them all done and have dinner on the table before you even get your first set of interviews done.”

“Speed,” echoed Scott, ”is what it is all about. You gather while we produce.”

“We don’t gather requirements,” protested Brian. “We gather information and then analyze the requirements from that information to make sure that the requirements solve the business problem. How are you going to know you’ve solved the business problem if you don’t even analyze enough to determine what the business problem is before you start?”

“We adjust. We adapt. We learn. We let the problem and the solution emerge through our collaborative activities. We don’t do the Waterfall thing with each group creating a document to pass on to the next group. Everyone works together in agile.”

“So, why not have business analysts involved with the collaboration? I think we have plenty to offer. After all we are the organizational communicators and problem solvers. We are part of the team.”

“Not in Scrum you are not. Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.* And we don’t want any groups of business analysts lurking about either. Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.* In other words, there is no place on our development for anyone but developers. Tough luck, Gatherers, you need to find a new job.”

Ann, Brian and Raj looked at each other and then back at Ken and Scott as they walked down the hall. As the two of them reached the corner, Scott turned to the business analysts and shouted, ”Oh, we’re having a memorial service for the Waterfall later this week. You’re invited. And the business analyst might be next to go.”

Ann pushed her blond hair across her forehead in her signature gesture and asked, “So, what are we going to do? The eight of us had been assigned to the Backbone project and Helen over in HR said that she has already gotten the official request for transfer for all of us. And she said she doesn’t really have anywhere to put us since marketing is supposedly going all agile and they have most of the new projects.”

“What are our options, Raj. You know more about this than we. You’ve been working a bit with the web guys”

“There are only three roles in Scrum: product owner, scrum master and developer. The product owner represents the business and provides the work to be done by means of the product backlog. The scrum master helps the team with the Scrum process and removes obstacles to the team’s success. And the developers write code and test.”

“That’s it?” said Ann. “I think we are doomed. I need to get my resume dusted off.”

“No. Not yet.” Said Brian. “I have an idea.”

“To get them to back off agile?” asked Ann.

“No, I think that ship has sailed.”

“Then perhaps to sabotage the ship so that it sinks, and they call us back in to rescue the project and survivors?” suggested Raj.

“Excepting of course, Ken and Scott,” Ann added.

“No, not that either, although that does sound appealing.”

“Then what?” asked Ann as they entered the lunch room and saw the rest of the business analyst team huddled together in the corner over their lunches and looking very worried.

“I recall something about the definition of the development team that Scott didn’t mention: Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. *” Ann stepped away from the counter to take a cell phone call.

“Yes, Brian, that is true,” responded Raj, picking out a salad, “But everyone on the development team must be able to code. Everyone is a developer. You are not supposed to have someone who is just one specialty.”

“Right. But here’s the thing, Raj. The development team is supposed to be cross functional and consist of “generalizing specialists” as Scott Ambler says, right?” Raj nodded. “Then we suggest that each of the three pilot teams take Jennifer, Jocelyn and Stan. They are all recent programmers who have moved into business analysis. They have the coding skills, and Jocelyn also has testing skills, so they are already generalizing specialists. They would bring their facilitation skills to the mix and make it easier for the teams to talk to the business. They also bring some business acumen that the developers don’t have since they have been working on this side of the house for a while.”

“But they will not be business analysts anymore?”

“No, that’s true. I don’t think any of us here will be business analysts after this. It is after all a New Order.”

“That is fine,” said Raj helping himself to a bowl of watermelon and mixed fruit while Brian picked a slice of double chocolate cake and wished the organization’s cafeteria served beer or wine with lunch. “But that is only three of the business analysts. What about the rest of us? Certainly you cannot code anymore. It has been at least twenty years since you last coded.”

“True. And no one uses PL/1 and ALGOL anymore anyway. I mentioned those three because I know they have technical skills and probably would not mind being back in the technical fray again. There may be many business analysts who are capable of applying their technology training or experience and can leverage that technical ability with the facilitation and communication skills they picked up as a business analyst. They would actually be doing more true business analysis work than if they just transcribed requirements from the business community.”

“OK,” smiled Raj. “That is a solution. But only a partial solution.”

“Guys,” interrupted Ann as they were paying for their lunches. “I just got off the phone with Helen. She says that the organization is instituting some belt tightening measures. There will be layoffs. They are going to start with all the older employees and move to those who support the older technologies. Anyone who is not specifically spoken for and that means business analysts who are not attached to a project.”

“That means all of us.”

“Except Jennifer, Jocelyn and Stan and any other business analyst who can morph into the role of Scrum Developer.”

“Brian, you have any other ideas?”

“Looks like you will be burning the midnight oil again tonight, Brian.”

Now there was an even more pressing need for action and ideas. The organization has announced There Will Be Blood. Will our own Captain Midnight be able to rescue the rest of the business analysts (including himself)? Will the Bell Toll for business analysis as well as Waterfall? Will Ann get to eat lunch? Join us next month for another thrilling episode of Brian and Ann in the New Order od Agile.

Don’t forget to leave your comments below.

* Quoted from Schwaber & Sutherland, The Scrum Guide: the definitive Guide to Scrum: the Rules of the Game, published by Scrum.org., July 2011

User stories – WHO wants them, WHAT are they and WHY use them?

Introduction

User stories are a popular technique for capturing high-level requirements. User stories provide the rationale and basic description of a new feature request. The following format is the most recognisable user story template:

As a
I want
So that

Agile teams adopting the user story technique often struggle with questions such as: WHO are user stories produced for? WHAT do good user stories look like? WHY maintain user stories instead of more detailed requirement specifications? To answer these questions – I will recycle the who/what/why template of user stories.

WHO wants user stories?

  • Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories – ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
  • The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
  • Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT are user stories?

  • Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
  • Typical format:
    • AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveller), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
    • I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
    • SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.
  • Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
    • Independent
    • Negotiable
    • Valuable/Vertical
    • Estimable
    • Sized Appropriately/Small
    • Testable

WHY use user stories?

  • Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items were reduced as part of a promotion)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories (not vice versa) – all requirements should have a user justification.
  • Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
  • Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project silos.
  • Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.

Conclusion

User stories provide the team with a method to capture and discuss high-level requirements. Good user stories follow the INVEST acronym and provide the user’s justification for a new feature. Within Scrum/Agile teams – user stories provide an abstraction of requirement details – this facilitates maintenance of the backlog and provides the team with a “placeholder for a conversation”.

Don’t forget to leave your comments below.