Tag: Techniques

Deep Dive Models in Agile: Process Flows Pt 1

Written by Candase Hokanson on September 15, 2016. Posted in Articles. 1 Comment on Deep Dive Models in Agile: Process Flows Pt 1

This short paper series, “DeepDive Models in Agile,” provides valuable information for the Product Owner community to use additional good practices in their projects.

In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

The first in this series is the Process Flow. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables, Business Objectives Models, and Feature Trees.

What is a Process Flow?

A Process Flow is an RML People model that describes the steps that a user takes to accomplish a goal or finish a task. This model is great for understanding the project’s current and future state processes of the business and understand those processes from the end user’s point of view.
RML Process Flows are created in levels in order to both be able to see the big picture of a process within a system as well as drill down into the details of a single more detailed process. This is in contrast to huge process maps with over 100 steps that try to show it all – but are unreadable! At the highest level, generally called the L1 level, the entire end to end process for an end user in a system is described, usually in 7-10 steps. This level tends to have no swim lanes or decisions to be made, so it is very abstract. See the top row in the example below:

From there, each step in the L1 process is broken down into the lower level processes, called L2 and L3 Process Flows. These are the levels that most people are comfortable talking about and eliciting. Each L2 or L3 process should be no more than 20 elements to keep readability, and even then should be divided by swim lanes to create smaller groups within the diagrams. L3 Process Flows are usually optional and are used if the process is large or complex of if there is a need to elicit that lower level of information to create requirements. See the example of an L2 and L3 Process Flow above.

When would I use a Process Flow on an agile project?

Process Flows are usually used for user-facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.

When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high-level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized, and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.

Once in the developing phase or in the sprints themselves, the PO or BA will look ahead (usually 1-2 sprints ahead) and determine if additional L2 or L3 Process Flows need to be built to either identify new stories for upcoming sprints or elaborate (via L3 processes) those stories already identified.
This can continue until the project ends. Additionally, the PO or BA, when doing their planning for upcoming sprints, may need to update existing L2 or L3 Process Flows with new information that has come to light. In this case, that time should be built in as part of elaborating the stories, and a common set of Process Flows should be kept so that they are up to date!

How do I create a Process Flow?

Process Flows are one of the easier RML models to elicit and create. To elicit the information, the BA or PO should discuss with the users and stakeholder the processes in the system today, who performs them, and when. Users tend to naturally think about the steps they take every day so this is usually a pretty easy model to elicit.

During elicitation sessions, you can bring draft or strawman models, to generate commentary and ideas. You can also start from scratch with a whiteboard, post-it notes, and the users to create the process.

For future state, the PO or BA will generally start with the current state process flows and elicit information from the users/stakeholders on what will change or be different in the future system.

The Process Flow model itself for RML has roughly 7 element types, of which, we’ll only cover 4 or so today. The elements we are not covering here are forks, joins, and events. All of the elements are connected together by lines with arrows that show the direction of the flow.

Step – The step is the most used element, as it contains all the process steps. This is typically a rectangle with short phrases in the form of subject-action-noun phrase (User logs in). These sentences should be kept short to get the point of the step across without understanding every nuance.

Decision – This element is typically shown as a diamond and describes a decision the user must make to move forward in the process. Decisions are most commonly binary (Yes/No), but can be non-binary as long as the options are all mutually exclusive and collectively exhaustive. Every decision diamond needs at least 2 options coming from it to be a decision.

Swimlanes – Swim lanes describe either the user or group of users who performs the steps or the system in which a series of steps or decisions are taking place. The swim lanes for a single process flow should be all of one type (either user or system) to enable easier understanding. Swim lanes are a way to organize the steps in a Process Flow to focus attention and save space by not having to repeat the user or system in each step.

Incoming/Outgoing Elements – Since RML Process Flows are built in levels, every lower level (L2 or L3) Process Flow should have an Incoming and Outgoing element. These elements are the “You are here” for the Process Flow set. They tell you what process step immediately preceded the current process and where the reader will go next.

How do I derive user stories out of Process Flows?

Once the PO or BA has good draft Process Flows to work with, he can start deriving stories out of the Process Flows to build or add to his backlog.

The level of story derived depends on the level of the Process Flow and the complexity of the process. In most cases, each step in an L1 Process Flow becomes at least one Epic user story (too big to fit into a single sprint). Each step in an L2 or L3 Process Flow becomes one or more User Stories for the backlog, and each decision can be as few as 1 user story or as many as 7 user stories. See the examples below.

Because user stories are written from the user’s point of view and Process Flows are created from the user’s point of view, Process Flows lend themselves very easily to identifying user stories. For example, if the Process Flow step is “User logs into the system,” then the user story is very similar and might look like “As a User, I want to be able to log into the system so that I can access my account information.”

Decisions are a little more confusing because if it is a lower level decision (say in an L3 Process Flow), it might be one story with the decision lines being acceptance criteria. If it is an L2 Process Flow, the decision might lead to a story for each branch of the decision diamond. For this, the PO or BA will have to use her knowledge of the team and the process to decide what is best for slicing up the stories.

Conclusion

Process flows are one of the easiest RML models to derive user stories out of because they are from the user’s point of view and allow the PO or BA to walk through a process systematically and write user stories for each step that needs to be supported.

However, one final point is that these Process Flows don’t need to be perfect or complete to be useful. The PO or BA can draft a process flow, review with users or stakeholders, and derive user stories from an incomplete one. As long as there is traceability between the process steps and the user stories, it is easy to know what to update if the process changes or where the gaps are if new steps are added. Additionally, even team members other than the PO or BA can edit and update the processed if they live in a centralized location.

In the end, these are one the most useful models we find on customer facing agile projects because they are quick to make and update and lend themselves very easily to stories at all levels of the agile requirements hierarchy.

Using Scope Models to Manage Solution Scope

Written by Aaron Whittenberger on August 17, 2016. Posted in Articles. 1 Comment on Using Scope Models to Manage Solution Scope

Organizations launch change initiatives (projects) for the purpose of delivering a benefit to the organization.

One thing that may cause those change initiatives not to deliver those expected benefits is scope creep. Scope creep is the unexpected and uncontrolled expansion of a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. Scope creep generally negatively impacts the project’s budget and/or schedule. Increasing project scope can also increase solution scope.

One way of defining and documenting solution scope is by the use of scope models. I do caution that this is not the only way of documenting solution scope, and multiple ways of defining and documenting scope should be used for every change initiative undertaken. Solution scope should be defined and documented in the way that allows the project stakeholders to understand the scope. Scope Models should create a shared vision of the solution scope amongst the stakeholders.
I am going to show you six scope models I use. There are definitely more models that can be used as scope models, but I find these to be the ones I use the most. Which models you use depends on the type of change initiative you are undertaking and what will describe the solution scope to the stakeholders the best.

Related Article: Using Feature Trees to Depict Scope

A Functional Decomposition depicts a subject and the breakdown of that subject into smaller buckets. This breakdown can be in multiple levels; meaning break down the subject into the highest level components, then break down those components into small components. This can be done to three or four levels. Functional Decomposition can be done on a feature basis or work basis. Using the feature basis, you would take a system and break it down to its highest level functions, as shown below. Using the work basis, you would take a work initiative and break it down to its highest level pieces of work; then break each of those pieces of work down to smaller chunks of work. This is useful to create a work breakdown structure and estimating work effort.

The Context Diagram depicts the system that is under discovery, the focus of your change initiative, and the external entities that interact with that system. These external entities can be systems, databases, websites, or business units (people). This model also identifies the data flowing between the external entities and the system under discovery, and depicts the direction of flow for each piece of data. One limitation of this model is that in only depicts external entities that directly interacts with the system under discovery.

A Process Flow illustrates high-level processes and the entities involved in those processes. A common process flow diagram is called a swimlane diagram. The swimlane diagram shows processes in a row, or lane, entitled by the entity that performs those processes. Several lanes are depicted in a swimlane diagram so that you can see the interactions and dependencies within the process, as shown below.

A Use Case Diagram is a representation of a user’s interaction with a system that shows the relationship between and the different use cases (functions) in which the user is involved. A use case diagram can identify the different types of users of a system and the different functions those users perform using the system.

An Ecosystem Map shows the system under discovery and the systems which send data to or receives data from that system. The major difference between this model and a context diagram is that the ecosystem map will show systems that do not interact directly with the system under discovery; that is upstream and downstream systems. As shown below, a website order entry system sends the customer order to the order fulfillment system, which sends product data to inventory system and purchasing system. The inventory system sends the inventory transactions to the accounting system. The accounting system also receives purchasing transactions from the purchasing system. Even though the order fulfillment system doesn’t interact directly with the accounting system they are both exist in the ecosystem; and therefore, are shown on the ecosystem map. The system(s) under discovery will be shown with a bolder outline than the other systems in the ecosystem map.

The Feature Tree is a fishbone diagram showing the features within the system. Much like the functional decomposition, the feature tree breaks higher level features into lower level features. Level 1 (L1) features are the highest level features and branch off the horizontal line of the diagram. Level 2 (L2) features are lower level features which branch off the L1 features. There is no reason to go beyond three levels of features. You can use color coding of the features to show what is in scope, out of scope or features in future releases. This is an excellent model to show executives, as it is a very easy picture that allows for a very quick understanding of the features being looked into.

It may be necessary to use multiple scope models to ensure that all stakeholders understand the solution scope of the change initiative. By using these scope models, as changes to scope are suggested you can determine if the change being requested is within the model. If it is not, you can caution the stakeholders that this may cause scope creep that will impact the project scheduled and/or budget.

Strategy Spotlight: 6 Strategic Spotlight Terms You Should Know

Written by Richard Lannon on August 3, 2016. Posted in Articles.

Recently I wrote about the importance of communications and having a common stakeholder language.

From a strategy spotlight perspective this is extremely important. Definitions and a common language help the business analyst keep people on track so they move things forward. Often I have to tell my stakeholders what the terms mean in the context we are using them in and that they cannot change the definition. This approach helps move stakeholders forward. In the strategic facilitation this is a valuable approach. Even if you are not doing strategic facilitation or planning, as a business analyst or project manager you need to know the key terms to align your work and project initiatives.

Here are six strategic analysis, planning and implementation terms I often give to clients to ensure that we are all speaking the same language and our work aligns with the over arching business requirements and stakeholders needs.

Strategy Agenda Item is a high level plan of action item designed to achieve a vision. Since strategic planning is a component of the business planning that is to be done before you take tactical action it is imperative that there is a clear understanding of the strategic agenda items as they provide focus. Often rather than focusing on internal operational issues, a strategic focus means addressing and solving business problems through the effective use of existing resources. As strategic initiatives are defined resource usage is analyzed.

Strategic Initiatives should represent the most significant line of business or cross line of business projects that are planned to improve the business in some way with consideration for the four key business impact zones. In this part of strategic planning phase the team is deciding the essential focus and key initiatives that must be met to achieve the strategic agenda items. Depending on the size of your organization these will become enterprise, program or project initiatives. They can be very strategic or tactical based on your organization’s size, structure and present culture. At the initiative level the way you define success in the attainment of our objectives should be clarified, the speed and distance of action determined and the critical success factors defined. This takes a while to do.

Business and Initiative Champions are individuals that go beyond their operative responsibilities. As defined here, they are individuals trying to influence strategic issues larger than their own immediate operational responsibilities. They take the initiative and accept responsibility and accountability for it. The potential ways and objectives of championing cover the whole process of strategy: the formation of the content of strategy as well as the process of implementing strategic contents.

If the focus is more of being an initiative champion then that person should bring discipline and rigour to planning and execution of an initiative ensuring the timing and achievement of milestones and deliverables are agreed upon and managed. They will need to tie investment in strategic items and strategic initiative to specific and measurable outcomes and enable issues to be addressed and resolved proactively, before they jeopardize outcomes.

A champion can be used more specifically to refer to a senior manager who champions the project, ensures that it is properly resourced and uses their influence to overcome barriers for the team.

Measurable Outcomes are the measurable results of the implemented objectives and must be defined in measurable terms. Measurements are essential for understanding what is happening in your business–what gets measured gets done. In a business environment, measurements come in many forms and include hard, soft, lagging and leading indicators.

Lagging indicators are used to measure performance and allow the leadership team to track how things are going. Because output (performance) is always easier to measure by assessing whether your goals were achieved, lagging indicators are backward-focused or “trailing”—they measure performance already captured. Just about anything you wish to monitor will have lagging indicators. Leading indicators are precursors to the direction something is going. Because leading indicators come before a trend, they are considered business drivers. Identifying specific, focused leading indicators should be a part of each business’s strategic planning and decision-making process.

You can pre-determine or reverse engineer measurable outcomes by either using the SMART and/or CAR principle. As part of the measurable outcome determination always consider key stakeholders.

Key Elements are the big things that need to be done in order to be successful. They are the big buckets of work. The key to creating key elements is to understand the scope of work at a high level and to be able to state them clearly. A scope of work sets forth requirements for performance of work to achieve strategic and project objectives. The scope of work must be clear, accurate and complete. It needs to be understood by a wide audience. Defining key elements is part art and science and takes a while to master.

Milestone is one of a series of numbered markers placed along a road. Within the framework of strategic planning, a milestone is a special event that receives special attention. It is often falsely put at the end of a stage to mark the completion of a work package or phase. Milestones should be put before the end of a phase so that corrective actions can be taken. In addition to signalling the completion of a key deliverable, a milestone may also signify an important decision, which outlines or affects the future of an initiative or project. In this sense, a milestone not only signifies distance traveled (key stages in a project) but also indicates direction of travel since key decisions made at milestones may alter the route pre-determine in the various plans (strategic, tactical or operational).

Final Thoughts

Whether you are working on a top-down, bottom-up or mid-level initiatives having clear definition of these terms will help you. It is very difficult to walk into a room and write a list of terms on a white board and ask people to define them. You will spend a lot of time on an activity that should be done prior to meeting. I believe the professional provides the words and defines the terms that will be used. I have provided variations of these terms when working with clients to align their thinking, to build or interpret roadmaps and plans already created and to ensure stakeholders had a common language. I invite you to adapt them for your own use. Good luck.

Always
Do your best,
Invest in the success of others,
Make your journey count.
Richard
Article adapted from SET for Success, Chapter 15, by Richard Lannon

Strategy Spotlight: 8 Ideas for Creating a Common Language and Communication Plan

Written by Richard Lannon on July 19, 2016. Posted in Articles. 1 Comment on Strategy Spotlight: 8 Ideas for Creating a Common Language and Communication Plan

While visiting a Director of Enterprise Analysis at a large utilities company, we started to discuss their key challenges.

They had lots, but the one we honed in on was the need for a common language and a communication plan to improve communications among stakeholders.

This is a challenge for most organizations.

So how do you go about creating a common language and a communication plan to make your efforts easier?

Here are 8 ideas for creating a common language and communication plan for your initiative.

1. A Communication Map or Plan

As part of your process, you need to discuss communications early from both an internal and external perspective. Whatever message you will be delivering needs to be consistent. In today’s world of click-of-a-button information and communication dissemination, there’s no leeway for inconsistent messaging. We no longer have the luxury of writing complex communication plans. Nowadays a communication map must have the message and all channels of communication in one place with a single view.

2. Clear Definition of Words and Terms

This is one I have worked on for every assignment I have ever done, and it is not always easy. In one of my training programs, Gathering and Documenting Business Requirements, I get the participants to develop a decision grid for going to a restaurant for dinner at the end of the day. Each team has to pick three places, identify their criteria and apply a rating system (which I supply) to make a decision and come to a consensus. The participants think this is simple to do when they start but as they work through the process they discover it is not always easy. Why? Lack of a common language.

Related Article: Improve Communication for Better Collaboration

Often the criteria for selection becomes words like the restaurant must be close, accessible, good food, good service, have character, etc. I always have to ask the participants to define their words. For example, accessible could mean: a) that the restaurant is on the right side of the street so no one has to make a left turn into traffic, b) that you can park on the street and get out of your car and just walk in, or c) that people with wheelchairs have easy access to the restaurant and all the facilities. One word with different interpretations requires you to create a common language.

3. It’s Going to Happen One Way or Another

No matter the work you are involved in, communications is going to happen one way or another. So you need to come up with an approach that allows you to get ahead of the communication curve. One of my highly successful business associates told me last week that to get ahead of the communication curve you need to “be everywhere”. From their perspective, you need to have a social media plan with your message and words clearly defined, timed and placed consistently both internally and externally to your business environment. The thing to remember is communication is going to happen anyway. People will talk. So you need to ensure that you are out there delivering the message everywhere.

4. Give the People What They Want

Interestingly, what management thinks motivates people and what employees say is rarely the same thing. Management tends to think wages and job security are the most important factors for people, but many employees prefer inclusion, involvement, and to be appreciated for their work. This sentiment might vary depending on the working generation being reviewed, but in general, people want communication. They want you to have a conversation with them, not to merely tell them what’s going on and what to do. Given a lack of communication, people will invent their own ideas. As a professional, it’s important that you take the lead and make sure you’re providing the right amount and right level of communication for people.

5. Focus on Your Audience

Today it’s especially important to know your audience, especially considering all the possible communication channels and mediums available and the specific needs of each target audience and sub-audience. To avoid speculation, you’ll need to create an effective communication program that is audience-driven. You need to go back to your stakeholder analysis and revisit interests, goals, motivation, impact, and influence. This will allow you to design a communication platform that connects with your audience—both internally and externally. Your common language and communication map should make the distinction between the internal and external stakeholders, as well as establish a connection with your stakeholders. The main point, though, is to make sure you address your audience’s needs.

6. Know What You Need

There is no purpose to having a common language and communication plan unless you know what you want to achieve. Is it high-level or are you trying to communicate with the people who are responsible for the work itself? The people who are responsible are the doers—they get stuff done. The people who are accountable are where the buck stops. These are different audiences with different information and communication needs. Another difference, you will need to consult with some people, yet only keep others informed. Make sure you’re clear on who is who.

7. Core Items to Consider

There are many items to be considered when you’re looking at your communication plan and the development of a communication map. Identifying and finding the best way to communicate with your audience will be the key to your successful implementation of your plans. The communication analysis and planning process is similar to the overall work you do as a business analyst or project manager – you’ll still need to consider your stakeholders’ wants and needs. You’ll also need to find the appropriate vehicle to communicate the overall goals and objectives, the plans features, benefits and values, and find a way to address your stakeholders’ questions.

8. Follow a Structure

A common language and communication plan follows a structure. Start with defining your language early on. You may need some people to help you with this. You can start filling in a communication plan early for your different stakeholder groups. Make sure your communication plan is revisited regularly, perhaps as part of the regular meeting, once a month or every two months. Make sure you re-evaluate it after six months, however, and revisit it as part of your lessons learned review. The truth is creating a common language and a way to communicate becomes a living document that you need to review and keep up-to-date to ensure you are communicating appropriately in your business organization. It needs to stay alive.

Final Thoughts

For reference purposes this blog has been adapted from the book SET for Success, and the chapter on communication plans and maps. When it comes to communications, we all need a common language and a communication plan in our work and business. It’s the last piece of the puzzle and is part of the analysis, planning, and implementation cycle from the beginning to the end. More importantly, it’s part of the implementation and transition process that ensures your initiative gets successfully implemented. If you would like a copy of my communication template, let me know. I will send it to you.

Remember,

Do your best,

Invest in the success of others, and

Make your journey count.

Richard.

Feature Thinking vs Value Thinking: What’s the Difference and Who Cares Anyway?

Written by Angela Wick on July 13, 2016. Posted in Articles.

How do you start your requirements process? Many agile and traditional teams start their process by defining features. While I don’t always disagree with this approach, it’s a potentially dangerous and slippery slope if teams are not careful. The mindset or context you use to begin your requirements process has a huge impact on the time, cost, and quality of the product or solution.

Feature-thinking does great things for architecture and system design, but if not kept in check, teams can completely miss the human and value factors.

Let’s look at an example:

A pizza company hired a team to build a smartphone app to order pizza. The pizza company wants to focus more resources on creating quality pizza vs. answering the phone. They want to reduce the number of calls to the pizza shop by getting customers to order via the app. They want customers to prefer using the app vs. calling the pizza shop to submit an order.

So the team gets to work. They start by asking, “OK. What do we need this app to do?” Their requirements approach begins by brainstorming features. They think of things like: Profile Management, Order History, Build Your Pizza, Payment Wizard, Notifications, etc.

This may seem like a logical way to begin, but this feature-focused mindset often leads teams down the path of over- or under-engineering their solution. It creates a risk to solution/product quality.

The problem is not the feature-thinking itself, but what gets shoved aside when features dominate the thoughts and dialog of stakeholders. In most cases, value-thinking sits on the sidelines—we forget about the value the solution brings to our users and our organization. Let’s follow our pizza shop example to provide some context for 3 pitfalls of “feature-thinking” to avoid.

1) Don’t let “feature-thinking” consume the problem/opportunity.

The team is NOT building a pizza ordering app; they’re solving a problem. What might happen if the team remains focused on the app and its detailed features instead of the opportunity to make a better pizza by reducing phone calls? Teams might:

exceed what is needed from a minimum viable product perspective
get distracted by secondary features and compromise the quality of the features that have a direct impact on the problem/opportunity
waste time and money
create a product that has so many bells and whistles that users are overwhelmed, don’t use the app, and continue to call in their orders

Features can help teams discuss the problem or opportunity at a high level, and detailed feature thinking is critical to great software engineering and architecture, but features by definition are a functional capability of the solution. When teams operate in a solution mindset, they tend to jump to technical details. Especially in the early stages of a project, describing feature usage and value context without doing technical design is the key.

When discussing features, be sure to ask: What part of our problem will this solve or what aspect of our opportunity will this help us take advantage of? If this focus is lost, value is compromised.

2) Don’t let “feature-thinking” devour the customer.

“Whom will it benefit and how?” This question MUST regularly be asked during feature-focused discussions. Because feature-thinking focuses on the solution, teams need user advocates with a value-thinking mindset—someone who will help the team brainstorm feature ideas by focusing on customer needs.

When our pizza shop team member starts the requirements discussion with, “What features does the app need?” A BA can reframe the question by asking, “What do the customers need the features to do?” Or better yet, “What is critical to achieving the vision of customers wanting to use the app vs. call?” It’s not the feature that’s important! We need the team to focus on the results of the feature and how the results serve the customer need.

When I see a team entering this danger zone, I like to ask them to step out of the feature for a moment. I ask them to brainstorm two different types of scenarios—scenarios that meet the user’s needs and scenarios that do not. Getting the team to brainstorm many manifestations of the feature helps the team see the feature from a user and value perspective.

Back to the pizza app…..let’s look at a feature called “notifications.” What ways would this feature enhance the user experience, negate the user experience, or have a neutral impact on the user experience? We may generate ideas like this:

As a customer, I want to receive a notification that my order has been started, so that I know it is in progress.
As a customer, I want to receive a notification when my pizza is in the oven, so I know the progress of the order
As a customer, I want to know when the delivery car is within 500 ft of my house, so I can make sure the dog and kids are out of the way when I answer the door and have a less stressful interaction.
As a customer, I want to receive a notification of when my favorite pizza is on sale, so I don’t miss an opportunity to save on my favorite meal.
As a customer, I want to order the pizza from a notification of a promo so that I don’t need to tap too many times to act on the promo notification
As a customer, I want to be able to ask the app to remind me of a promo when I read a notification and mark the notification as “remind me in ____.”

All of these scenarios have different architecture implications for the notification feature, yet not all of them bring value to our pizza shop customer or our pizza shop workers in the context of our goal to minimize calls. Which ones add value and which ones don’t?

How would you analyze and prioritize features based on what matters to the customer? What do they expect at a minimum and what will they not even care about? This is minimum viable thinking at work!

3) Don’t let “feature-thinking” eat the pizza. (Focus on value!)

If we lose focus on the problem we are trying to solve and the customer needs we are trying to meet, then our features will eat our pizza—they will consume all of the value the team hoped to provide for the organization and its customers.

Features maximize value when they align with and are prioritized based on the core mission of the organization and the needs of the customers. Keeping this focus will keep you in check and prevent you from under- or over-engineering solutions. It’s all about creating really good pizza, happy customers, and a thriving business.

In many cases, feature-thinking can be a great place to start, but beware of the risks. Don’t minimize the value of a product or solution—put the human and organizational goals back into the requirements.

Do you start your requirements process with features? If so, here are a few questions for you to ponder:

How do you avoid these three pitfalls and keep your team focused on organizational and end-user value?
How could you change your requirements process to begin with value-thinking?
What would a value-driven requirements approach look like?

Please leave your answers/comments below.