Author: Angela Wick

The Business Analysis of Agile Product Ownership

Written by Angela Wick on June 14, 2016. Posted in Articles. 1 Comment on The Business Analysis of Agile Product Ownership

I’ve been giving an Agile Product Ownership talk at a few conferences lately and the response has been great. BAs and BA leaders are beginning to see their connection to product ownership functions, but they are also discovering that there is a huge gap in the industry about what product ownership means.

They want to understand the scope of the product owner role, how the role fits in various agile methodologies, and how the product owner and the BA work together. As teams learn more, it is evident that product ownership extends much further than most teams realize.

For example, most agile methodologies place the product owner focus on the backlog, but do not offer guidance on how to build, prioritize, and refine the backlog. Also, some agile methodologies recognize the need for a product vision, roadmap and release plan, but again, offer little guidance on collaborative techniques needed to build these effective tools. Yet this is a HUGE part of the role!

Related Article: Technical Product Ownership

What surprises me most when I work with teams, teach this topic, and present on it is the giant number of teams that do not have a product vision, or teams that create a product vision, but never use it. This bugs me! It ranks near the top of my “How to Work Hard, but Create Crap” list. Without a product vision that is aligned with the organization’s strategy and customer value, we are seriously compromising the money being spent. Is it really possible to have a prioritized backlog without a baseline vision and value proposition?

Product visions provide many benefits. You wouldn’t do a waterfall project without understanding the problem or opportunity or update systems in a large organization without a roadmap that aligns the technical and business strategies? Why would agile be any different?

When your team starts digging into the details of requirements and user stories, they need to see connections to the product vision. They need to understand how their work supports the purpose of the product, the goals of the organization and/or the needs of the end-user. This is true for projects, but it’s also true for enhancements and defect fixes too! Even a backlog of defects and enhancements to an existing internal system can benefit hugely from a product/solution vision.

Whether your team is building a new product or modifying and existing product, you need a product vision. If your team doesn’t have a product vision, here’s what happens:

The team projects their own ideas and values into the solution.
The team makes unconscious (sometimes conscious) assumptions and decisions about what the true business problem is.
The team assumes the user group or requestor has thought through the proposed solution and its impacts, while the user group assumes the team is thinking through it all.
Ultimately the team creates fixes, enhancements, and solutions that do not meet the needs of the customer and require rework.

You are probably reading this and thinking, “Yes Angela I agree, but my leadership team is not providing this vision information! They only want the solution done yesterday!”

Most leaders I talk to about this scenario tell me that they want their teams to question vision and value, and would rather postpone the date then spend money on something that does not align. Leaders are assuming that if teams don’t ask, then they already understand the vision and strategy. That’s why they get so disappointed when the solution does not deliver the intended value.

Here are some tips to help BAs and Product Owners advocate for the importance of the product vision:

Highlight lessons learned. If past solutions moved forward without aligning to strategic intent and value, remind your leaders about mistakes, reworks, and defects. Connect with their pain in this, and then explain how you and the team will fix it.
Create a draft. Create a product vision, write a problem statement, or use a tool like a vision board, product canvas, or business model canvas to confirm your understanding of the context of the product, solution or fix. Discuss how the proposed solution impacts the various areas of the organization.
Discuss the extremes. Generate dialog or create simple models that help the team think about what an over- or under-engineered solution would look like.
Prototype. Build a prototype of the design or in-progress solution to get feedback.

Vision discussions throughout the solution lifecycle lead to better requirements, less rework and defects, high-value solutions, and happy end users.

The shared vision/purpose promotes a high-quality decision-making process. We want to avoid making assumptions and decisions for the business owners, and put the right information in front of them to make or delay decisions. Collaborative discussions between the team and the stakeholders, eliminate the blame game. Leaders get what they need to evaluate time/value trade-offs.

How does your team keep requirements and solutions aligned with organization strategy and end user value? Please leave your comments below.

5 Things the Legendary Musician and Artist Prince Can Teach Us

Written by Angela Wick on May 2, 2016. Posted in Articles. 1 Comment on 5 Things the Legendary Musician and Artist Prince Can Teach Us

When I sat down in a Canadian hotel room to write this article for BATimes, I had a completely different topic in mind—a rant about the length of TSA pre-check lines and how bad processes make life miserable for users. But as I was writing, I became more and more distracted by the news of Prince’s death. Social media started blowing up with Prince memories, pictures of buildings and monuments bathed in purple lights, and videos of spontaneous tribute parties in front of Prince’s Paisley Park headquarters and First Ave, one of Prince’s favorite clubs in Minneapolis.

As a legendary musician and artist, Prince influenced my life in many ways.

Minneapolis is my hometown, and it’s where Prince grew up and lived most of his life. When I was a kid, purple was my favorite color. Raspberry Beret was like a theme song for recess in elementary school—I sang it non-stop with friends on the playground. Purple Rain was one of the first movies I saw in a theater, and I grew up wondering what 1999 would be like.

It may seem like a stretch to use Prince’s approach to music and life as a metaphor for business analysis, but creative genius is universal and can inform our approach to all areas of life, including project work.

So, in tribute to Prince, here are five things BAs (and all people?) can learn from Prince’s legacy.

1) Be unique in expressing your talent, blaze a trail!

Prince blazed a trail of creativity and innovation. He released 39 albums in his 37-year career and is rumored to have several hundred additional songs in his Paisley Park vault. At the same time, he lived in Minnesota, not California. He didn’t swear. He wore heels. He was often seen riding a bicycle through his neighborhood and enjoyed ping-pong.

What would the BA equivalent of this career path look like? How could BAs use their analytical, creative, empathetic, and relationship-oriented talents to generate volumes of innovative work in an authentic way?

We have this awesome role we provide to organizations that can be uniquely executed and performed in our own individual style and personality with success! Embrace it, go with it! Know your mission as a BA and live it!

2) Unleash creativity.

Prince was a master of unleashing creativity in himself and others. He was passionate about collaborating with others to discover new sounds and create new music.

As BAs, we are called to model creativity in our approach and to inspire others to be creative as well. Creativity takes many forms in our work including:

Building strong relationships with stakeholders.
Identifying and applying the right technique to elicit effective requirements.
Utilizing techniques that create a collaborative culture that encourages good dialogue from all perspectives.
Using advanced facilitation skills to help others find innovative solutions to problems.
Mastering analysis techniques that help others make good decisions.

3) Create for everyone!

Just as Prince’s music resonated with multiple types of audiences, so should our requirements. Our work as BAs requires us to create and facilitate for multiple audiences and diverse stakeholders. We are masters of catering to multiple audiences:

introverts and extroverts
technical and non-technical
leaders and subject matter experts

4) Surrender to your art.

The sheer volume and variety of work Prince produced indicates an all-consuming passion and commitment to his craft.

What would our BA work look like if we approached it as an art? What would it mean to surrender to our art as BAs? Perhaps we would:

Be more confident in our role and mission.
Advocate for the strategic importance of our role.
Define a unique approach for each project/situation rather than complying with cultural norms or taking direction that might not benefit the organization or the end customers.
We would hone our craft by finding mentors and collaborating with peers to learn new skills and techniques.

5) Experiment.

Remember the vault with hundreds of unreleased songs? Prince never stopped experimenting. Prince hosted surprise concerts all the time. He would just jam and experiment, inviting others to participate and react.

Experimenting with technique is critical to mastering our BA craft as well. We experiment to learn. We try new things to see how they feel and to see how our stakeholders react. We apply new techniques to deliver and drive value to our organization and its customers. We try new things even though we might fail and we learn and adapt when our experiments don’t yield expected results.

Prince inspires by being himself and bringing so many together. How has Prince inspired you? Please leave your comments below.

From The Archives: User Stories And Use Cases – Don’t Use Both!

Written by Angela Wick on April 11, 2016. Posted in Articles. 5 Comments on From The Archives: User Stories And Use Cases – Don’t Use Both!

We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn’t the only thing we discussed, we are also a social group ;-)).

We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.

We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.

Differences and Similarities

So what are the differences and similarities between User Stories and Use Cases, and when do we recommend using the different tools?

Use Cases

A Use Case is “an end to end sequence of interactions between an actor and a system that yields a result of observable value to an actor, usually the instigating actor”. Um, so what does that actually mean? Generally a Use Case (the textual description, not the stick figure diagram) is written as a flow or sequence of steps in the format

Actor does something
System does something
Actor does something else
System does something else
…

A Use Case is made up of one main flow and a number of alternate and/or exception flows some of which can branch back to the main flow.

Now Use Cases are by nature fairly detailed – they describe the steps in an activity and the points in the flow where things can change. To produce a useful (can be given to someone to build from) Use Case you need to define the set of interactions in quite a bit of detail, you need to understand what the business rules are that govern the activity, the options that the actor will have available to them when undertaking the activity, the ways things could go wrong and what bits of information are needed in the flow of interactions. To do this you need to spend quite a bit of time and effort analysing the activity and producing the document. This is BDUF – Big Design Up Front which is the antithesis of Agile.

User Stories

User Stories were originally a reaction to this big up front thinking. When Kent Beck defined eXtreme Programming (XP) he came up with the concept of a User story as a tool to support the iterative and incremental approach which is inherent in all the Agile methods. Mike Cohn went on to write a book which explained what User Stories are and how they are used in Agile projects. In addition to these two, Jeff Patton publicized the technique of Story Mapping to show how User Stories can be used to cover the breadth and depth of functionality needed in a product.

The key to writing good User Stories is to understand that the intent is not to provide the detail early on in a project, but to provide a framework where the detail can be added as it is needed, just enough and just in time. Drawing on the work of Beck, Cohn and Patton and many others the generally accepted approach to producing User Stories and using them to guide the development of the product follows a decomposition approach.

The decomposition comes in the form of a story map. The beginning of a story map is defining the Backbone stories – the key User Activities or Tasks which need to be accomplished to do the work of the product, the large discrete chunks of functionality which need to be delivered to be able to say we have solved the problem. These large chunks are often referred to as Epics (a big story ;-)), they equate to an elementary business process, something that is done in one place, at one time, by one person. Comparing this to Use Cases, this would be the result of the Use Case survey – a list of the discrete elements of the product, goals of the actors.

When building a story map, these Epics are normally laid out in a single row showing the logical sequence and handoffs between the steps in the process. Visually these Epics will be written on a different colour card to t e User Stories which will come later.

Image: An Example of a Story Map – Epics in green along the top

Epics can be put in sequential order along the top (if sequence is appropriate, which it normally is).

The next step in the Story Map is to populate the map with the User Stories that fall under the Epics. Each User Story is a small, discrete piece of functionality that has value to some user of the product and is a decomposition of the Epic above. The most common format for writing User Stories is “as a (role) I want (feature or capability) so that (business value to be delivered)” –

As an internet banking customer I want to list my account balances so that I can understand my financial position.
As an internet banking customer I want to list transactions on an account so that I can check the detail

The three elements are important – knowing who the story is for helps ensure we build a useable product, what the functionality is that is needed and the value which will be derived from having that functionality enable us to make good priority decisions.

Related Article: Technical User Stories: What, When, and How?

Priority based on business value is very important to defining User Stories. Knowing the value from a story enables us to make good decisions about the sequence of work – building the most important business value components first and getting feedback early rather than trying to build everything at once is inherent to Agile.

The User Stories are the orange cards in the image above.

Priority and Sequence Shown in the Map – identify the MVP

One of the benefits obtained by building a Story Map that shows the logical flow of activities (from Epic to Epic along the top) and the discrete elements of those Epics vertically down the page is the ability to clearly see both sequence and priority. Stories that are higher up on the map are more important (needed sooner) than those lower down.

The prioritisation and sequencing approach enable the discovery of the Minimum Viable Product (MVP) – those elements which need to be delivered to provide the opportunity to learn and adapt the product based on feedback from real customers/users. Finding the true essence of the product and getting that into the hands of real customers (probably just a small subset initially but enough to get feedback to validate the assumptions being made in the development of the product).

In a real-world internet banking example, the very first version of the product which was put in production had the ability to log in and to list balances and this version was used by the project team and a small group from within the bank. Having this “walking skeleton” built and put into production validated the architecture of the product, identified a number of unexpected challenges with the deployment process and gave the team feedback about their design philosophy which enabled them to make some significant changes when they were cheap and easy to do.

The Elements of a User Story

In his book, Mike Cohn says that a User Story has three C’s – the Card, the Conversation and the Confirmation. The Card is the initial User Story, written on an index card or PostIt note. This is deliberately short and devoid of detail. The intent is to defer the detail until later in the project, just ahead of when this piece will be delivered. The detail is established through the second C – Conversations. As the project progresses and elements are delivered there will be a number of conversations that result in clarity of understanding about what is actually needed to deliver the value identified in the User Story.

The final C is Confirmation – these are the Acceptance Criteria for the User story – the details which will enable the customers and the technical team to agree that “if this story meets these criteria it is done”. This is the detail which is all too often left out in bad Agile projects (“Tragile”). This detail needs to be agreed to, and it will contain whatever is needed to enable the delivery of this component of the product. The key difference between Agile and other approaches is when we produce this detail. In an Agile project this will be produced collaboratively with the customer representatives just ahead (a couple of hours to a couple of days) of when the piece will be built.

The most common format for these acceptance criteria is the structure of Acceptance Test Driven Development. Each user story will have a number of acceptance criteria and may also have other elements which will help ensure the right thing is built – these could include screen mockups, technical notes, models such as class diagrams and whatever the team needs to enable them to deliver the business value.

Examples (for the list account balances user story)

Given the customer has one credit account and one savings account
When they have logged in successfully
Then the two accounts will be listed in account number order (Account no, Name, Balance, Available Funds)

Given the customer has no accounts
When they have logged in successfully
Then a message indicating that there are no accounts to show will be displayed

Given the customer has twenty one accounts
When they have logged in successfully
Then the first twenty accounts will be listed in account number order
And a Next Page option will be enabled

Given the customer has twenty five accounts
And they have logged in successfully
And they are on the first page of the list
When they activate the Next Page button
Then the list will be cleared
And the list will be populated with the last five accounts
And the Previous Page button will be enabled
And the Next Page button will be enabled

Gojko Adzic’s book Specification By Example provides an excellent reference on how and when to produce acceptance criteria.
Ultimately the Acceptance Criteria will be proven through a set of test cases (ideally automated) which show that the product works as needed to deliver the business value.

Reduce Waste and Be Responsible

Again, the key to reducing waste and rework is to defer this detail until just ahead of when it is needed, rather than trying to clarify it all up front. Things will change over the life of the project and deferring the detail makes it cost-effective to adapt to this change.

However – taking this just-in-time approach is not an excuse for poor architecture or bad design. Early on in the product development it is important to set clear architectural guidelines, design principles and deal with what Philippe Kruchten calls the “Architecturally Significant Non-functional Requirements” – those aspects which will be extremely expensive and difficult to refactor later. Note however that we say “guidelines” and “principles” – don’t try to build the complete architecture up front, allow it to be emergent inside the boundaries of these clear guidelines.

Traceability in User Stories

Hopefully it is clear from this description that User Stories actually have a powerful traceability mechanism built into the design of the technique.

There is a cascading one to many relationship:

A Role or Class of User derives value from one or many Epics
One Epic could have many User Stories
One User Story will eventually have many Acceptance Criteria
One Acceptance Criterion will have multiple Test Cases which prove it is working as expected

This traceability is enacted through the “so that” component of the user story, which ensures that every piece which is implemented has a direct relationship to the business value to be derived from that component/capability.

Timing Makes the Difference

The key is the timing – User Stories are deliberately abstract early on in a project and will evolve over time on a just-in-time and just-enough basis. This is because Agile projects expect and anticipate change and respond to this change by adapting the product to the evolving needs. More User Stories will be added, some will be dropped and our understanding of many will change as time progresses. The reality of today’s business world is that change is inevitable, so trying to define the detail of all aspects of the upfront will result in lots of wasted effort and time as much of the work will need to be redone.

The Story Map is a fluid and changing tool – as stories are completed they are removed, new ones added and change is accepted as a normal part of the way we maximise the delivery of value to our stakeholders and the organisation for whom the product is being built.
The detailed Acceptance Criteria for any User Story will on be produced just ahead of when it will be delivered, maximizing the amount of work not done (one of the 12 principles of the Agile Manifesto)

One of the mistaken and dangerous myths of Agile is that “Agile projects have no documents” – the reality is Agile projects have the documentation that is needed to ensure value is delivered, and nothing more. The philosophy is to defer work until just ahead of when the output of that work is needed (a concept inherent in Lean thinking) and only do that work which is necessary to achieve the desired outcome (preventing waste from unnecessary effort and rework).

This is in stark contrast to Use Case thinking where the goal is to define in the various flows of the use case all the detail of the requirements up front. This approach will inevitably result in wasted effort as the use cases will have to be maintained and updated as the changing needs emerge. In agile we want to evolve the solution iteratively and incrementally as we learn based on feedback from real customers/users, not rework the documentation and requirements.

Could you use Use Cases instead of User Stories in an Agile project?

Theoretically Yes – you could indeed use Use Cases instead of User Stories to express the business needs. None of the Agile approaches are prescriptive about how you express the list of capabilities/features the product must contain (what Scrum calls the Product Backlog), however we see significant risks in trying to do so. Use Cases miss the mark on the “WHY”; they are not well suited to expressing the separate pieces of business value and supporting the iterative, incremental approach to developing the product – they tend to be monolithic and encourage an “all or nothing” way of thinking vs. an adaptive evolutionary style of learning and discovering the solution together through quick build and feedback loops.

Could you build Use Cases after developing an Agile solution to document the requirements after the fact?

Theoretically, yes . . . however with this approach you have missed out on a critical technique in User Stories to guide conversations towards maximising value and minimising extra work throughout the development process.

Risks and Dangers of Use Case Thinking in Agile Projects

Compromised Innovation
- Use Cases bring on a lot of detail before getting feedback on a built product. This cognitively brings user mind-sets into a predefined interaction and solution, negating the potential for further innovation. The exploration and learning aspect is compromised and focus goes from solving a need to perfecting an already defined solution.
Compromised Timelines:
- Too much detail before building compromises the benefits of time in the Agile approach. Spending time detailing out Use Cases is spending time on what and how when we be should focusing on the why. Defer the what and how until just ahead of when it is needed
Compromised Value:
- Use Cases confuse the role of Acceptance Criteria in User Stories and agile. Many teams are using Use Cases as an alternative to creating Acceptance Criteria for their User Stories. Acceptance Criteria evolve in levels of detail as builds iterate and evolve and more is learned together through the agile process. This learning process is where the value lies as the needs are quite unknown before starting.

Conclusion

Many teams embarking on their Agile journeys are finding comfort in techniques used in the past for requirements definition, particularly Use Cases. Use Cases resemble user stories in more detail, and User Stories were developed as a condensed technique to alleviate the lack of WHY in Use Cases and to alleviate too much detail too soon when using an Agile approach.

We believe that User Stories and Acceptance Criteria are the techniques aligned to deliver the benefits of the Agile approach and Use Cases compromise and put the benefits of the Agile approach at risk.

Teams thinking about using Use Cases should strongly consider looking at the methods and evolutions of defining Acceptance Criteria (especially the model) with many scenarios and levels of detail that evolve as feedback through the iterative cycle and delivering increments of the product as it evolves. Keeping with user stories (Including story maps & epics) along with well defined and evolving acceptance criteria will meet the goal of leveraging the benefits of agile without putting timeline and value at risk.

Don’t forget to leave your comments below.

About the Authors

Shane Hastie

Shane is the Chief Knowledge Engineer and Agile Practice Lead for Software Education, a training and consulting organisation based in Australia and New Zealand, working all around the world.

Shane teaches courses and consults around business analysis and agile and is passionate about bringing the two communities together.
He is a member of the board of the Agile Alliance, and is the lead editor in the Process and Practices community on InfoQ.com
He can be reached at [email protected] and on twitter as @shanehastie

Angela Wick, CBAP, PMP

Ms. Wick is passionate about inspiring innovative BAs and is a leader in the business analysis field. Angela is a trainer of business analysis, project management and in bringing innovation and creativity to these roles. She enjoys working with traditional and agile teams, and especially in preparing teams for agile in their organization. She also consults with organizations in building BACoEs, BA practices, BA Career Models, and BA competencies. Angela is a lead contributor to the BABOK v3 and the IIBA Competency Model. Angela is also a monthly blogger on BaTimes.com

Angela can be reached at [email protected] and on twitter @WickAng

Both Shane and Angela are Core Team members for the IIBA team building version 3 of the Business Analysis Body of Knowledge (BABOK)

Is Your Project Manager-Business Analyst Collaboration a Pressure Cooker?

Written by Angela Wick on April 5, 2016. Posted in Articles.

Is your project’s red-yellow-green status for requirements based on percentage complete of the requirements document?

Or percentage complete of the JIRA stories documented?

Maybe this is why requirements are taking so long!

Is the focus on the status of the document or the progress toward shared understanding of the problem and solution?

{module ad 300×100 Large mobile}

It is important to honor the priorities of both the project manager and the business analyst. One can’t win out over the other or the end users might suffer. So, how do we find the right balance? How do PMs and BAs come together to support each other while standing up for the essence and integrity of their roles?

Project Managers – Do you know what it takes to collaborate with BAs to get great project results? Are you encouraging BAs to be leaders of their domain?
Business Analysts – Do you understand the value of the BA role and how the PM can support and enhance your practice?

Tight timelines and fixed solutions apply tremendous pressure to interactions between PMs and BAs. The pressure triggers negative PM and BA behaviors. I’ll highlight some of these behaviors below and offer insight to inspire better collaboration.

Pressure #1: Tight Timelines

Tight timelines put pressure on the entire project team. When documents like BRDs are tied to unreasonable durations in the project plan, BAs feel like document dispensers:

Tight Timelines Mindset to Change – Get documents done NOW!

What does the “Get Documents done NOW” mindset look like:

The PM lets the BA know timelines are really tight.
The PM asks the BA to draft documents ASAP.
BAs start filling out templates and then use the review process as an elicitation technique to get them reviewed approved “quickly.” (FYI-It’s not faster! It’s actually a long, painful process that stakeholders loathe, BUT…)
Stakeholders get used to reviewing text-based documents and tolerate the process because it’s the only process they know.

Tight Timelines – A Collaborative Alternative

Modern PMs and BAs understand the drawbacks of the “write-review-repeat” cycle—it actually takes longer and produces unstable, ever-changing requirements.

Related Article: A Collaborative Stakeholder Process

Why? Well, because the team never gets a chance to collaborate and develop a shared understanding of the big picture and the real problem the team is trying to solve. They only understand their piece of the puzzle and cannot see connections or gaps that may have prevented defects or maximized the value of the solution.

Instead of forcing text-based document review from day one, the team should support a requirements process that includes dialog and analysis with stakeholders. The BA should be using elicitation and modeling techniques to facilitate structured conversation with stakeholders about the current state, future state, people impacted, process, data, rules, etc.

Once there is a shared understanding, document writing, review and approval move along quickly. Overall, this collaborative approach is faster and yields higher quality requirements.

Tight Timelines Mindset to Change – Minimal BA Planning

What does the “Minimal BA Planning” mindset look like:

The PM owns the project plan. (What BA plan?)
The PM sets a milestone for requirements sign-off or sprint commitment on the plan.
The PM focuses on the date/deadline and the document (or tool) vs. the quality of the requirements process.
BAs may or may not have experience or training in creating BA plans and a quality requirements process. Either way, they may follow the PMs plan without discussion or negotiation.

Tight Timelines – A Collaborative Alternative

PMs should encourage BAs to design their own approach. PMs and BAs should collaborate on the plan, timelines, who is involved, and what is truly needed to get to good requirements. The team should meet with the sponsor and get agreement on the quality expected and plan for requirements accordingly.

Tight deadlines may be ok if time and cost are the drivers of the project. Rework and quality issues might be worth the pain to get it done by a date. But, if quality, user experience, data integrity and getting users to love the solution are the drivers, then speeding up requirements and focusing on deadlines and documents will spell disaster.

Pressure #2: Fixed Solution

It’s always surprising to me how common it is for project teams to start their work wearing the blinders of an assumed solution. BAs are basically asked to reverse engineer requirements for a solution that floats down from above:

Solutions tossed down to the BA, before analysis, tend to promote the following behaviors:

Fixed Solution Mindset to Change – Don’t Ask Questions!

What does the “Don’t Ask Questions” mindset look like:

The stakeholders communicate their want (not their true needs).
The stakeholders (sometimes on their own) identify a solution, and it is rarely a complete solution that is analyzed and well thought out.
The PM and the stakeholders pressure the BA to crank out a requirements document.
No one explores the true needs of the end-user and, therefore, no one knows if the predefined solution meets the true needs of the end-user or the organization.
Gaps/issues are ignored, placed in a parking lot, or found along the way or after go live, creating a long backlog of enhancements.

Fixed Solution – – A Collaborative Alternative

In my experience, stakeholders rarely ask for the right solutions. There is always more—a twist and a turn that yields a different solution than requested. Rushing a solution that was never really vetted, yields endless scope changes, increased defects, and unhappy users.

That’s why, as tough as it is, BAs need to appropriately challenge predetermined solutions and help their stakeholders think.

PMs need to support the BAs, even under tight deadlines, to explore true needs and generate options/alternatives. The PM and BA should work together to help the sponsor understand the risks of moving forward without analysis.

Fixed Solution Mindset to Change – Deep Rooted Bias

What does the “Deep Rooted Bias” mindset look like:

Everyone (PMs, testers, developers, product owners, end-users, etc.) is aware of the solution at the beginning of the project.
The sponsor and the stakeholders agree to validate the solution.
The awareness of the predefined, but not yet analyzed solution creates bias that limits the team’s ability or motivation to see/identify alternatives.
The BA doesn’t push for deeper discussion because the team is ready to move forward with the stakeholders’ plan.

Fixed Solution – A Collaborative Alternative

The BA’s primary role is to advocate for value! This should be a ruthless focus—much more important than the perfect document. BAs need to courageously ask the PM and the team for time to make sure the solution is value-oriented, not just first-idea-oriented.

Easing the Pressure

A collaborative partnership between PMs and BAs requires:

• PMs and BAs who understand their role and are leaders of their domain.

• PMs and BAs who can clearly communicate and advocate their perspectives and priorities.

• A shared understanding that trust and teamwork will maximize solution value.

How do you build bridges between business analysis and project management in your organization? Please leave your comments below.

Bring Your Requirements Practices out of the ‘80s

Written by Angela Wick on March 7, 2016. Posted in Articles. 11 Comments on Bring Your Requirements Practices out of the ‘80s

What are you hanging on to? What do you need to purge from you project closet? Still fond of the requirements equivalent of MC Hammer parachute pants, jackets with shoulder pads, stirrups, acid wash jeans or jelly shoes?

If you’ve been using the same requirements approach since banana clips, and popped collars were all the rage, then you might not realize your processes are outdated. So, just like my old Teen Beat magazine, here’s a little quiz:

Do you find yourself trying to document everything perfectly before reviewing with stakeholders?
Do you find yourself defining the current state in the finest of detail before working on the future state?
When you need some ideas for requirements models, do you pull out the big three-ring binder from your BA training or methodology training from 1989?
Does your team still call it “Requirements Gathering”?
Is scope creep and changing requirements the evil sins on the project? Do you do everything in your power to avoid them?
Does your team have a strict/elaborate/red-tape-filled change control process?
Do you need to write specification level details that developers can code from—telling them exactly what and how to code it?
Do you need completion/approval of text-based templates before projects can move forward?
Does your requirements approval process include multi-hour review sessions where stakeholders review lists and paragraphs of requirements line-by-line?
Are requirements are prioritized by first-in, first out (for those working on enhancement lists)?
Are ALL requirements the HIGHEST priority (for those working on projects)?
Does the QA team need user interface detailed design to start with test planning?

If you answered yes to any of these questions, it’s time for a little spring cleaning. Let go of the old practices that slow your progress. Make room for a few new things. Modernize your requirements process!

{module ad 300×100 Large mobile}

But why? If your current process seems to be working just fine, why would you change?

Skepticism and cynicism are understandable. You’ve seen dozens of methodologies, approaches, tools and techniques come and go and come back again, just like neon, leg warmers, and fringe. Your process is like the classic black suit or basic black boots—timeless—right?

Yes, there are obviously foundational pieces of requirements management that will stand the test of time, but some mindsets, techniques, and processes require a modern twist. Here are a few items you should consider removing from your project closet:

Outdated Mindset: Scope Creep and Change are Bad

Change has transformed from preventable/bad to expected/good/healthy. The pace of change seems to be increasing rapidly. Changing requirements can mean many different things:

We missed the requirement earlier. (This is probably still bad and preventable.)
Stakeholder thoughts about the future have evolved through the process. This is expected and good! It means stakeholders are engaged in meaningful dialog, and they are thinking critically. They want to maximize value for the end-users and the organization. So, when your stakeholders seem to “change” their mind, try to reframe the change as an evolution or discovery of thought that is making the solution better than previously thought of; ultimately making the organization better off.
External or uncontrollable factors create change. Obviously, these changes can be blessings or curses, but they are expected in most industries. The increasing pace of change trickles down to our projects. We need to accept and embrace these external forces to be better than our competitors and serve our customers.

We can’t prevent change, and we must be adaptable. If we keep thinking change is bad, we will waste the organization’s resources and create uninspiring solutions.

Outdated Approach: Finish Requirements Before Experimenting or Prototyping

Experimenting and prototyping should not wait until a “build phase” after requirements. Instead, use experiments and prototypes to elicit and refine requirements.

As the complexity of our organizations increase over time, prototyping and experimenting become more important. Unknowns, ambiguity, and risk drive project teams to “try stuff out” before building and/or buying. As BAs, we need to identify the high-risk features that are most likely to change and use experiments and prototypes to get to clearer requirements. It is okay that our stakeholders do not have all the answers, many times an experiment or prototype will show them what they need to clarify their requirements.

Outdated Practice: Detailed Technical Specs

Do you find yourself writing detailed technical design specs that developers use for coding? If so, ask yourself if they help or hinder your process. Here are my concerns:

Developers and their team (Tech Lead, architects, etc.) should be able to take relatively technically agnostic requirements and provide options and alternatives that meet stakeholder requirements.
If you write technical specs without getting a shared understanding of the business requirements (sans technical details), will you really meet the needs of your end-user/customer? Your stakeholders are not experts in technology. They think they know what they want, but their narrow viewpoint may limit the solution. This approach might introduce risks and constraints that diminish potential value. It’s normal for stakeholders to express requirements this way, but it’s our job to reframe the requirement so that the technical team can use their expertise to bring options and alternatives to the table.

Outdated Process: Shared Understanding Through Text-Based Templates

Say goodbye to the days of multi-hour meetings to review and approve giant requirements text templates, line…..by……line. Was this ever a good practice? I would say no, but many organizations take this long, slow and painful path to shared understanding because they don’t see an alternative.

But there is an alternative and it’s faster, with a better end result. Develop shared understanding iteratively through engaging conversations, structured workshops, and collaborative games that focus on:

Who (actor/user role group)
What (action the user group performs with the solution)
When (in what flow of other tasks, and under what conditions)
Why (why must this user perform the task)
Visuals for context
Matrices for detailed rules and logic
Non-Functional Requirements (System and feature level)

Then, after you reach shared understanding, you can complete your templates if needed. (I find that most organizations have trouble letting go of their templates, just like I can’t seem to part with my old Walkman and my rainbow colored hair scrunchie collection.)

Have you recently eliminated an outdated requirements practice? If so, let me know what and why in the comments below.