Skip to main content

Author: Angela Wick

Want Faster Requirements? Build Them Like a Snowman!






“Requirements take too long!” That’s the message I am hearing from organization leaders across the country. That sentiment leads directly to pressure on BAs to get requirements done faster. Unfortunately, the most common strategy to speed up requirements is actually making them take even longer.

In most cases, BAs under time constraints start with their end-product, the formal requirements document, or perhaps user stories in a tool like JIRA. They find their standard requirements template or open JIRA and get to work, robotically cranking out requirements—usually alone, in their cube.

Then, BAs schedule a requirements review with the team. The review stirs up lots of questions and concerns which leads to a very long cycle of reviewing and re-writing. BAs get frustrated because stakeholders keep changing their minds and scope begins to snowball, downhill, out of control dashing everyone’s hopes for speedy delivery.

The documented requirements is the output, not the value we provide!

As BAs, we need to take control of that scope snowball. We need to keep its size and speed in check, so we aren’t always lagging behind. So let’s replace the image of that out of control snowball with a happy, stable snowman.

When you gather a group of friends to build a snowman, each person arrives with their own big picture. Each person comes with a mental model of what the solution looks like based on their previous experiences and imagination.

angelaFeb 1

As a BA, your goal is to blend and merge these diverse perspectives and create a shared understanding of the snowman with the critical decision makers. If you start the process, by documenting formal requirements, before you reach shared understanding, you will be presenting something like this to your friends:

  • The snowman shall wear a black top hat with a yellow flower.
  • To keep his neck warm, the snowman should wear a red scarf.
  • To keep him stable, the snowman should not have more than three tiers.
  • The snowman requires a carrot nose.
  • The snowman requires temperatures to remain below 32 degrees to prevent melting.
  • The snowman shall smoke a pipe.
  • The connection between the base and the body should be at least 4 inches wide.

Of course, your friends will react because your documentation looks nothing like their big picture. They may not be able to see how the details fit into their vision, or they agree with parts and details and then change their mind as they listen to others. It seems like they keep changing their minds.

  • It’s hard for the users to compare the words to their big picture.
  • They can’t easily identify gaps.
  • Issues will arise, but in a random order over a long period of time.
  • Users can’t see the connections between components.

Using formal text documentation to elicit requirements is not an efficient approach. Documentation may be needed as a deliverable to document the output of elicitation; it’s just not an effective process to build shared understanding. When we start with formal text documentation, we work really hard, but it’s a false sense of progress because we are not actually moving forward. We get stuck in a never-ending cycle of:

angelaFeb 2

We CAN start with the end in mind, but we CAN’T start at the end if we want to speed up the process. Let’s flip the approach. Instead of spending 80% of time reviewing and re-writing, spend 80% of time on elicitation and analysis. Use collaborative techniques to build requirements with the team, piece by piece and layer by layer.

Back to our snowman. I am from Minnesota, and we could argue that we are darn good snowman makers here! We have a constant pack of snow on the ground for about 4 months of the year. I am sure others that live with snowy winters can relate!

A snowman starts with one small snowball. As you roll the snowball, layers of snow begin to stick. As it gets bigger, you need more and more friends to help you keep it rolling. Your friends will agree when the snowball is big enough to provide a foundation:

angelaFeb 3

You repeat the process again for the other components of the snowman:

AngelaFeb 4

Every expert snowman builder ensures stability by packing extra snow where components connect:

angelaFeb 5

Then, the team begins to accessorize:

angelFeb 6

At the end of the process—after all of the collaboration, models, discussion, debate, etc.—you document your requirements:

angelaFeb 7

And guess what? Everyone nods their heads in agreement, without 20+ rounds of “review and re-write.”

Why is this collaborative approach more efficient than the “write and react” approach? How does it speed up the requirements process?

  1. It’s easier for your brain. From a cognitive perspective, our brains can’t process text well. The brain needs images and engaging dialog to work through complex ideas.
  2. Stakeholders participate early and often. If they participate in building the components (models, diagrams, matrices, tables) that make up the requirements deliverable, they will have more trust, fewer questions, less fear, more confidence and offer more support through the project lifecycle.
  3. It takes less time overall than the painful review/rewrite process.
  4. There’s less rework. Effective elicitation and analysis techniques make gaps, dependencies, and constraints more obvious which allows the team to manage issues earlier in the requirements process. It minimizes requirements rework generated in testing and after release.

Getting requirements done faster means more elicitation and analysis and better (more engaging) techniques.


{module ad 300×100 Large mobile}


Instead of starting with text-based requirements templates, we should use elicitation and analysis techniques that inspire meaningful dialog including visual models, matrices, and collaboration games.

It may seem counterintuitive, but spending more time on the front-end of your requirements to create shared understanding before cracking open that formally documented end state, will speed up the write/review/validate process. If you get everyone on the same page first with effective elicitation and analysis, then documentation and review become a rubber stamp and requirement processes will be more effective and efficient.

What is working for you to speed up requirements? Leave your comments below.

4 Habits Agile Teaches That We Can All Refocus on in 2016!

Agile was born out of a conversation about what works well in software development. It wasn’t meant to be a dramatically “new” way of working. In the context of requirements, embracing agile empowers teams to focus on business value, user experience, and empathy, and collaboration. This focus should be applied to all projects no matter what approach we take or what methodology we use.  

With this in mind, we need to question our current solution delivery practices. When did our focus shift away from our users? How did we lose our connection with our organizational mission?  When did we stop questioning the value of each task we perform as part of the project? Why do we dread meetings and prefer to hide in our cubes instead of collaborating with our team?

We’ve lost touch with our core values, but what’s driving this divergence? Here are a few trends that may be influencing this:

  • Organizational governance and methodologies that focus on and measure the completion of documents and templates.
  • Resource reductions caused by the economic downturn in the early 2000s. Smaller teams did not have the capacity to provide maximum value; they were pressured to do the minimum, and the minimum was defined by templates.
  • The rise of the PM role in the 90s and early 2000s where time and cost (of getting documents completed) took precedence over the delivery of value.

“Going Agile” may not solve this problem. I would argue that many agile teams are more focused on sprint timelines, ceremonies, and velocity, then on value, collaboration, and user experience. Isn’t this the same conversation that inspired the agile mindset—just different words for schedule, cost, and productivity? So, are we really embracing the agile principles if this is happening? Or are we just looking at it like a “new” methodology?

What does “Going Agile” really mean to your organization? And, to you as a BA? Are requirements practices and value being left behind? Many agile practices, principles, and values remind us of business value, user experience, and collaboration; but why should it take a mature agile practice to do this?

Let’s get back to what matters as BAs! The documents, models, diagrams, and all the meetings are important too, but let’s remember why we are doing all of it! Let’s use the four strategies below to regain our focus. Let’s make value, user experience and collaboration part of our mindset, our behaviors, and our way of working.  This can be, and should be a large part of our practices no matter what approach or methodology we use.

1. Focus on organizational value every day.

BAs provide value by keeping their team focused on the mission, vision, strategy, and goals of the organization. Every product/solution detail should align! BAs apply this agile strategy by asking themselves and others questions like:

  • How does this solution benefit the organization? 
  • What part of our mission does this product support? Does it offer strong support? How could we change it to better serve our mission?
  • How does this list of project priorities align with our organizational strategy? 
  • Which parts of the project help us achieve our mission faster? 
  • Which organizational goal does this feature help us achieve? 

Ask value-focused questions during every phase of the project, but especially when you are:

  • Identifying needs
  • Eliciting requirements
  • Assessing risks
  • Prioritizing features
  • Resolving issues
  • Building release schedules

2. Make user experience and user empathy a priority.

The goal of any product/project/solution is to delight the end user and, therefore, strengthen the organization. We tend to lose focus on the end user when we get bogged down in the day to day details of delivery. Our focus often shifts to the needs of the delivery team. We start talking about protocols, databases, interfaces, integrations, and upgrades, instead of user needs, user preferences, user priorities, and user experience. In addition, we need to think about and discuss how aspects of the user experience align to the business value discussed above.

To delight your end users, integrate tasks and techniques into your project work that help your team:

  • Understand the end user’s needs and goals.
  • Understand how the user’s goals align to and support higher level business goals.
  • Analyze user pain points to find the root cause of problems. 
  • Uncover your end user’s thoughts and feelings about the current state and future state. 
  • Prioritize/make decisions based on value to the end user and alignment to the organization.

Great BAs use a wide variety of techniques to help their team keep user experience top-of-mind, but here are a few suggestions: 

  • Create, build, and analyze personas, and their linkage to value and strategy.
  • Use empathy maps to analyze value and user experience.
  • Allow users to interact with prototypes.
  • Get input/feedback from user focus groups.
  • Build user stories that are truly from a user perspective and show business value.
  • Ask user-focused questions: How will this benefit the user? Does this feature align with the top 3 user goals? How could we improve the user experience?

3. Facilitate engaging, collaborative and structured conversations with stakeholders before documenting requirements.

Documentation needs to be secondary to shared understanding. Great BAs use a variety of facilitation techniques to help the team understand purpose, value, and context before requirements are written. 

BAs need to create an environment where all team members contribute to meaningful conversation. When BAs focus on learning and discovering, instead of just collecting and recording, they will boost their team’s ability to navigate complex change. Here are the key components of engaging and collaborative conversations: 

  • Use simple, high-level visual models to get discussions started.
  • Allow team members time to react to each model and help them update the model collaboratively.
  • Do not expect to create shared understanding in one meeting. Progressively dig deeper into details with additional visual models. 
  • Allow thinking time in between sessions. Encourage stakeholders to share models with their team, and to identify questions, gaps, and concerns. 
  • Analyze the results of each collaboration session to make the next session productive, helping the team move steadily toward their goals.
  • Let the team weigh in on what needs to be documented to move forward—only document what’s valuable. 

4. Question the value of everything we do (and are asked to do) as BAs.

We can dramatically change the results when we understand the “why” behind everything we do. The why defines the value of each task and helps us act efficiently on that value proposition. BAs should ask themselves and their leaders:

  • What value does this task, requirement or feature provide?
  • Who gets value out of the artifacts we produce? 
  • Why are we doing it? Because we always have, or because someone “expects” it?  

Don’t let fear drive the team to do a bunch of busy work. Recognize fear as the driver and ask yourself and the team if this is really something the team should be spending money on? I like to ask myself:  “If this was my home we were improving, would I spend the money to pay someone to do this?”  If the contractor said he needed another $50,000 to create a 300-page spec document to remodel my home, what questions would I ask before handing over and approving that spend for a document?

Don’t waste time on things that don’t provide value for the user or the organization. 

Your BA approach should be different for each project and your organization should allow flexibility. If your organization requires templates, documentation, procedures and processes that do not add value, advocate for change. Can you influence what is produced, when it is produced, or how it is produced? 

What’s Your 2015 Lightbulb Moment?

As the year draws to a close, it seems natural to pause and take a look backwards. Instead of beating ourselves up for the well-intentioned goals we left in the dust somewhere around January 13th, let’s focus on the things we did accomplish, and look towards a new year.

So, in the context of your professional life:

  • What did you learn this year?
  • What new technique did you apply?
  • What challenge did you overcome?
  • What was your 2015 lightbulb moment?

Below, you’ll see my response as well as a few great contributions from my social media community. I hope you’ll consider sharing your answer to one of these questions in the comments below the article!

My 2015 Lightbulb Moment: The more things change, the more they stay the same!

Our field of work is evolving, and it seems like the pace of change increased dramatically in 2015. Consider these events/trends as indicators of change:

  • Expanding definition of agile business analysis
  • IIBA releasing BABOK v3
  • Increased collaboration between BAs and Product Owners
  • Evolving Product Ownership landscape
  • Increased demand for agile BAs
  • PMI marching forward in the business analysis/requirements space
  • Resurgence of user-centered design and design thinking

My learning this year has been focused on these themes and keeping up with how organizations are adapting and changing. Individuals, teams and organizations are understanding these changes and what they mean in a variety of ways!

Related Article: 2015 Trends in Business Analysis and Project Management

This is a lot of change for an industry, and yet so much remains the same:

  • Business analysis is required! It doesn’t matter who does it or what their title is, business analysis is an essential component of effective solution and product delivery. If business analysis doesn’t happen, we build the wrong stuff.
  • Effective business analysis adds and protects value! When organizations make changes, business analysis ensures the solution aligns with the needs of the organization and its customers.
  • Business analysis is still about delivering value through the user, the process, the data, and the rules.
  • The key skills needed to be a great BA (facilitation, communication, negotiation, change management, etc.) still apply!

Align Tactical Effort with Strategic Goals

From Doug Goldberg, @DougGtheBA: BAs must align tactical effort with strategic goals. First step: define business need/problem. Second step: learn business architecture concepts.

Yes! Business architecture is making a more formal appearance in our work. Organizations are seeing the need to connect the architecture to the business analysis and requirements work. This is cool stuff!

And, of course as Doug points out, our work is fruitless if we don’t understand the need first. An early understanding and continuous reminder of “why” helps us stay focused on delivering value. We treat our organization’s money as if it were our own and squeeze every penny out of our solution.

In recent classes, I’ve used the analogy of remodeling your house. If you hand over a large chunk of money to a design/build firm to remodel what would you expect? You would want the team to bring cost/value/time trade off decisions and opportunities to you, right? It’s the same for our sponsors. BAs work with sponsors to align the tactical solution with the sponsor’s strategic goals.

#Accountability

From Tim Kramer, @kramerscycling: In order to be successful the culture needs to change from “Can I do xyz?” to “My intent is to complete xyz.” #Accountability

Intent is everything! And so is delivery! Can we understand our stakeholder’s true intent? NOT what we think they want, NOT what they say they want, but really, truly, undeniably, seek to understand their intent? Yes, we can, and then we need to deliver!

SLACK!

From Ilya M, @Matveyich: Slack is a messaging tool that provides fast and effective collaboration with my team, group discussions, and document sharing. We’ve also integrated product monitoring.

Fast and effective collaboration is a HUGE theme this year! Teams regularly experiment with new tools and processes that boost collaboration and efficiency. We need to bust out of our silos and share information, so we can maximize the value we deliver to our customers.

Tools like Slack, can be a great resource for teams, especially when they can’t be face to face. However, like any virtual communication, be sure you are not relying 100% on text. Get visual, check for understanding frequently, and relentlessly encourage dialog over documentation.

Specification by Example

From Kristen Ericksen: My new go-to technique is specification by example. This technique makes it easy to talk in real terms, makes it easy to see and plug the holes in requirements, and gives the audience just enough to complain about, so I get the REAL requirements.

Yes! This is a great way to engage stakeholders! Examples create context and a common language for stakeholders. The team collaborates to identify examples that spell out what the solution needs to do. Everyone works together to build a shared understanding of the future state. And, as Kirsten points out letting stakeholders vent a bit does build relationships and trust, critical to success with requirements.

SHARE!

Thank you to Doug, Kristen, Ilya and Tim for contributing to this article. Let’s keep the conversation going! Use the comments below to boost our BA community by sharing YOUR favorite technique, tool or lightbulb moment from 2015!

Your Backlog Might be Broken If…Part 2

How does your project team build and manage their to-do list? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of project success or failure is the health the project’s backlog.

Poor backlog management yields inefficient and ineffective projects. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn, and value will be lost.  Successful organizations give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve but the overall goals and objectives are clear, the process is transparent and teams gain efficiency.

Strong backlog management practices:

  • Keep teams focused
  • Deliver value quickly
  • Inspire innovation and creativity

It can be quite difficult for organizations to objectively assess the health of their backlog management processes and even more difficult to implement changes.

In Part 1, I wrote about prioritization and inside-out backlogs.

In Part 2, we continue our journey by highlighting a few more characteristics of broken backlogs.

Your backlog might be broken if…there isn’t a guard dog.

Who builds, prioritizes and monitors the backlog? Is it a business analyst, project sponsor, product owner, project manager, development team manager or scrum master? Honestly, the mindset matters so much more than the title! The team can even manage the backlog together, as long as there is a clear decision maker.

Is anyone able to just throw something on the backlog? If so, do you have a guard dog that determines it’s priority, relevance and value? This person needs:

  • Knowledge of organizational strategy, goals and objectives
  • Understanding of feasibility and rough cost of features
  • Knowledge of stakeholder needs
  • Knowledge of end user needs and priorities
  • Authority to make decisions
  • Authority to modify the backlog

The guard dog should be vocal throughout the project lifecycle and shepherd team members to solution value. They need to advocate for organizational value and end users while helping team members understand how project decisions impact various domains, solutions, users, and the organization as a whole.

Related Article: Your Backlog Might Be Broken If…Part 1

Your backlog might be broken if…there are multiple backlogs.

Successful project teams put ALL of their incoming work into ONE queue. You can’t effectively manage priorities, time, cost and resources if there are multiple backlogs.
If you maintain multiple backlogs, how do you decide which work is most important? How do you clearly communicate priorities to the project team? How do you get the team focused on the most important stuff? Multiple backlogs create confusion and teams easily loose focus as they try to manage and work on multiple things at once.
If you value focus and efficiency, don’t derail the team’s work with competing incoming pipelines. Build one queue!

Your backlog might be broken if…there is too much detail.

Even if you do have a single backlog, it still might be broken! We need to address the idea that a single backlog of 100s of items is ridiculous to mange and prioritize. So, what gives?
Well, the backlog needs progressive decomposition! What does this mean? It means that items, as they are put on the backlog, and if not prioritized at the top, go into a larger category or larger feature. So, the further back in the priority, the larger, more ambiguous, more conceptual the item or feature is. This helps teams continue to see the big picture and prioritize based on value without managing 100s of items.

wickpart2image1

OR

wickpart2image2

The backlog should not be a detailed requirements document! Only the items coming up in the next couple of iterations need detail. The other items can be loose categories and higher level items until they are prioritized to the top of the list. Once prioritized, we can decompose them to the point that they are estimable into a sprint.

For example: A backlog item may say something like, “Add the shipping amount to the cart total when customers view their cart totals while shopping.” Once this is prioritized, and the team determines that this is too big for an iteration or sprint, we can decompose it into further detail to multiple items like:

  • For US shipping purchases and USPS shipping method, add the shipping amount to the cart total when customers view their cart totals while shopping.
  • For US shipping purchases and other shipping methods (FedEx, UPS), add the shipping amount to the cart total when customers view their cart totals while shopping.
  • For FedEx global purchases outside the US, add the shipping amount to the cart total when customers view their cart totals while shopping.
  • And so on…..

The team can again assess the estimates to complete these newer decomposed items and determine how much can fit into a sprint/iteration, de-scope, update priorities, etc.
Your backlog items only need enough detail to define the user goal and help the team prioritize the work. Don’t worry about the details until the item approaches the top of the backlog or until it has been assigned to be developed. On many agile teams the further details of the story get worked out once the sprint starts with the team through experimentation, prototyping, and conversation and feedback loops. This strategy will minimize rework and the need for detailed change control while the project evolves.

Your backlog might be broken if…there is not enough detail.

Does your team ever have features or stories that don’t get done in an iteration or sprint? It might be because the backlog did not have enough detail. Your backlog items should be more detailed as they climb in priority and get closer to entering a sprint.

However, many teams struggle to define “detail.” In this case, detail is enough information to allow the team to commit to getting the item done in the time allowed (i.e., a single sprint). If the team talks about the item and does not think it can be completed, it needs to be sliced further. Slicing further does not mean dividing it up into tasks, components, or technical design details! Instead, slice by decomposing the item into smaller, but still user-valued pieces, without getting into technical design details or team tasks.

Need a few slicing strategies that will help you avoid tasks and technical design? Try:

  • Process sub-steps
  • Scenarios
  • Business rules
  • State changes
  • Personas
  • User roles
  • Exceptions

Rephrasing can also help teams hone in on value. For example: An item that says, “upgrade the server” could be rephrased as “in order to use the new ‘profile update’ functionality, we need to upgrade the abc application to the latest version.”

Backlog items should not require multiple iterations to complete. SLICE THEM and DICE THEM, but make sure you break needs and features into distinct, logical, user-focused chunks of work. Getting backlog items to the right level of detail simplifies requirements, development and testing processes.

Is your backlog broken?

So, let’s go back to the beginning—are you building and managing your backlog strategically or simply building a to-do list without much thought?

Your Backlog Might Be Broken If…Part 1





How does your team build and manage their backlog? Is your current process working well or does your backlog need a reboot?

One of the most overlooked factors of team success or failure is the health the backlog. Success or failure often hinges on the amount of love and attention an organization gives to their queue of needs, features, feedback, bugs, and enhancements.

I am concerned that teams and organizations continue to focus too much on getting items developed faster vs. developing the right items—the items that add the most value to the organization. Traditional and Agile teams alike are experiencing these challenges.

Poor backlog management yields inefficient and ineffective projects/iterations/sprints/releases, and ultimately less value delivered overall. If you neglect your backlog and let it wander off, unattended, into the crowded project circus, it will dart to and fro distracted by every bright shiny object. Your team’s sense of direction will suffer, objectives will be murky, requirements will churn and value will be lost.

Successful teams give their backlog lots of TLC. They approach their backlog with strategic purpose—continuously reevaluating what’s most important and shifting it to the front of the queue. The items in the queue shift and evolve, but the overall goals and objectives are clear, the process is transparent, and teams gain efficiency.

Strong backlog management practices:

  • Keep teams focused
  • Deliver value quickly
  • Inspire innovation and creativity
  • Mitigate negative risk

It can be quite difficult for organizations to assess objectively the health of their backlog management processes and even more difficult to implement changes. These processes are often unwritten and entrenched years of evolving organizational politics, culture, and values. But admitting you have a problem is always the first step, so I’ve identified a few indicators that might shine a light on your broken backlog. Read and ponder the first two indicators this month and I’ll give you a few more to think about in Part 2 next month!

Related Article: 7 Habits of Highly Effective Business Analysts

Your backlog might be broken if…it is not prioritized.

How does your backlog get prioritized? What criteria are used? A healthy backlog delivers only the right work at the right time to the team. The most important things need to slide to the top and should be prioritized by value to the organization.

Prioritizing the backlog in traditional and Agile environments entails elicitation, analysis, and decision-making. As BAs and PMs, we may be the one facilitating this process, or as Product Owners we may own the decisions on the priorities. Either way, it’s our job to keep the development stream clean! Only items that yield true value to the organization should flow into development. We use tried and true analysis and elicitation techniques to ensure that each item is understood from an end-user and organizational perspective so it can be effectively prioritized.

If you are like many organizations your backlog may be 100s if not 1000s of items long. That seems impossible to prioritize! So, how do you deal with a backlog that is simply too long? Here are a few ideas:

  • Make sure the backlog is not just something the technical team is managing; it needs to be aligned with the business. The right business drivers should guide the backlog prioritization.
  • The top 10 (or about 10) items should be known and rank prioritized by value
  • When an item hits the top 10, elaborate additional details and requirements
  • The rest of the backlog can be grouped into like categories. Please do not categorize them by technical application, component or task, but rather by feature, process, or something of tangible business value that is understandable to the business decision makers.
  • Revisit the top 10 as often as needed to always have a top 10 in place.
  • Track the time something has been in the backlog…. seriously consider deleting/archiving the item if it remains in the backlog and not making the top 10 for six months (or whatever timeframe seems appropriate).
  • Make sure everyone knows the top 10 ranked priorities and get everyone focused on #1!

Warning: If your team seems to be using FIFO (first in first out) or SWGG (squeaky wheel gets the grease) processes for backlog management, the team is at high risk for not delivering value and spending the organizations resources appropriately.

Your backlog might be broken if…it is inside out.

Does your backlog focus inside out (technology and technical tasks) or outside in (user and business point of view)?

Backlog items should be written from the user or business perspective, NOT from the perspective of the team or the technology components. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.

To prioritize the backlog we need to understand the value each item provides by writing our backlog items in ways that express the value to the organization, end customer or end user.

When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. If your backlog items have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your backlog might be broken.

Backlog items should express the WHO, WHAT, and WHY, in terms that the end customer understands and can be prioritized by business leaders.

Some ideas to transition poorly written backlog items:

Item 1: Add a SAVE button at the bottom of the screen.

Rewritten: Give the customers the ability to save an order mid-stream while entering all of the order data so that they do not risk losing information already entered if they step away or get interrupted while entering.

Item 2: Upgrade the database to the new version

Rewritten: For customers to be able to enter orders after Oct 1st, 2015 we need to upgrade the database to the new version so that the version works on the operating system.

Item 3: Code the server file to add the new volume properties

Rewritten: To serve our expanding customer volumes we need to update the server file to accommodate more users at one time.

Is your backlog broken?

As you evaluate your backlog this month, ask yourself these important questions:

  • • How are our priorities really being determined?
  • • Are the items on our backlog written in a way that makes it easy to understand value and identify priorities?

Our backlog health check will continue next month when I share a few more “broken backlog” indicators in part two of this article!