Why Requirements Refinement Should Be An Ongoing Process


The year, 1998.  The place, some nameless IT office.  A young man is preparing for his first day of work.  He has no idea what a business analyst does, but he knows it has something to do with computers and will mean gainful employment for him.  His mentor sits him down and says, “Are you familiar with IEEE 830.”  He was not.  The mentor begins an intense interpretive reading session,

“1.2)  The system shall allow a user to buy a cake with a credit card
1.2.1)  The system shall accept Visa, Mastercard, and American Express
1.2.2)  The system shall charge the credit card before the cake is made
1.2.3)  The system shall give the user an order number…..zzzzZZZzzzzzzzZ”


Things have changed a lot since 1998

IEEE Standard 830 was last updated in 1998.  The internet was in it’s infancy, mobile phones were used to make calls and calls only, and your 17 year old nephew was a newborn.

In the meantime, the development of software has become more complex and more connected, while business costs and competition have increased.  Michael E. Porter of the Harvard Business Review writes, “… new types of products alter industry structure and the nature of competition, exposing companies to new competitive opportunities and threats.”  If you created the requirements for a 5 year program in 2006, there is a sea-change of events you could not have accounted for.  IEEE 830 was created in a time where you wrote requirements once and only once, and put a great deal of effort into “getting it right the first time”, because you didn’t have to worry about the industry being upended by the time the project was completed.

In the last 17 years, we have learned a lot about software projects and specifically requirements.  Namely:  Its very difficult to get them right the first time, up front.  If we know they wont all be right the first time up front, then we need a mechanism to constantly assess requirements against our original hypothesis and new information.  This is where ongoing requirements refinement comes into play.


Helps keep other supporting documentation up to date

A bad side effect of “nailing down” requirements up front is that we create reams of documentation the quickly begins to rot.  Meanwhile, the analyst who was engaged with the project for the first 6 weeks during the requirements phase has moved on and no one wants to take on the task of updating requirements, lest they be saddled with that duty forevermore.  Since the documentation is out of date, no one reads it.  Since no one reads it, it rots faster.  After a few months of this, the *real* information is in people’s heads (and in the code), and the requirements documentation is for suckers and newbies.

If requirements were revisited every 2 weeks on a cycle, it would be much easier for them to keep up with code changes, because we would only have to incorporate 10 business days of “new stuff” into the requirements.


Helps continuously align requirements to business priorities

One of the reasons the software changes after it has been spec’d is because there are emergent business priorities and opportunities that don’t care that the requirements have already been signed off.  One example of this is McKinsey’s article (full disclosure:  I’m a McKinsey alum)  that describes Amazon’s advanced customer segmentation, a technique that has only become available in recent years because of the explosion of online interactions and data processing capabilities.

A “rolling wave” of requirements refinement would allow an “opening” to re-prioritize emergent needs against existing requirements, allowing us to take advantage of innovations in mobile, analytics and cloud.  Of course, this is heavily dependent on the requirements being prioritized to begin with.  But that is another story for another day.

Until Next Time,

Stay Agile, My Friends

PS, Go here to get my “5 Signals A Requirement Should Be Deleted” tips

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Optimizing for “Developer Productivity” is a Useless Business Metric


“So we need to build cross functional teams where the developers can help out with the testing effort….”

“Wait a minute, are you suggesting our developers become testers?”

“I’m suggesting people help remove bottlenecks and help all the work get done faster.  Testing is a bottleneck, so helping with the testing effort will remove the bottleneck to getting more stuff done faster”

“But if we do that, our developers wont be productive.  I want them to be productive and focused on writing software!”

I’ve had this conversation, and many others like it with client over the years.  The unnatural focus on developer productivity continues to boggle the mind.


There is no objective way to measure developer productivity

News Flash, developers are not widget makers in a factory, their productivity can’t be boiled down to a nice, clean, objective, numeric measure.  We have all heard horror stories about companies who use “lines of code” as a measure of developer productivity.  Thankfully, that practice has gone the way of the dinosaur.  However, engineering leaders continue to search for that “one true metric” like Ponce de Leon searched for the fountain of youth.  He ended up with mosquitoes instead.


Creating a local optimization does not optimize the complete system

It’s easy for me to rage against the developer productivity argument, but that’s not my point.  My point is:  As we look for ways to smooth the flow from “I have an idea” to “This idea is making money”, we look for ways to remove bottlenecks.

The bottlenecks are what prevent us from creating value as quickly as possible (concept to cash).  One of the biggest bottlenecks of any development organization is the bottleneck that happens when 5 developers finish coding at the same time and there is but 2 lonely testers to try to validate the code.  This in addition to the regression, the test planning, and whatever other duties they have on their plate.  Heaven forbid they’re part of a “testing pool”, then it really gets gnarly.

When we optimize for the developers “productivity” rather than the system’s “flow”, we are intentionally creating a bottleneck and limiting the flow.  Not good.

Developer productivity is not a business outcome

Lastly, when I talk to organizations about Agility I always turn the focus away from the particular terms and jargon of Agile, and more toward what we really want, which is positive business outcomes.  Most businesses invest money into projects for one of three reasons:

  • Save Money (automating business processes, less expensive platform, fewer people needed to maintain)
  • Make Money (revenue generation opportunities, adjacent product market, vertical value chains)
  • Reduce Risk (compliance, redundancy, disaster recovery, unsupported platforms)

Focusing on these business outcomes and creating the conditions to objectively improve them is a much better use of time, effort, money, and energy than optimizing for a software engineer’s so-called “productivity”

Until Next Time,

Stay Agile, My Friends

PS, Click here to download my special report:  5 Useful Agile Business Metrics

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Unknown Problems, Sloppy Goals, and Unclear Success Measures – We Can Do Better

“Our project is to implement a new widget management system”, she stated confidently.  “Ok”, I said, “but what is the problem we are trying to solve?”

“We need a new system…”, she reiterated.

“Yea, but to what end?  Whats the business goal?  And how will we know when we have reached it?  How will we measure success.”

“Look”, she said, steeling her glance and locking eyes with me, “My job is to get this project done in 9 months with 500k.  No more.  No less.  I let the business people look after the business goals.  My job is to deliver on time and on budget.”

Like many others, the project became a morass of blaming, finger pointing, and misplaced expectations.

Here is a 3 step process to avoid some of these problems


Gain clarity on the problem to be solved

You should be able to articulate to stakeholders and the team what the problem is you are solving for.  This has a couple positive side effects:

It gives your team context.  Context is important because it centers the attention on the outcomes to be achieved, not the activities to be performed.

It aligns your stakeholders.  Stakeholders may think they’re aligned, but when you put a concrete problem statement in front of them, you will quickly find the difference in opinion and disagreement among stakeholders.

It helps greatly with prioritization.  No project ever in the history of software development projects has ever had enough time, enough people, and enough budget.  Effective management is the art of getting the highest value outcomes given your constraints.  Since we know we won’t be able to do everything that everyone wants, we have to decide whats most important.  Clarity on the problem to be solved creates a framework for prioritizing whats important (items that help us solve the problem), and whats not (items not directly related to solving the problem at hand).

Click here to get more information and examples of problem statements, goals and success measures


Create a qualitative goal to be reached

A goal is a way to describe the end state of the solution your team will be developing.  The purpose of a goal is not precision (we will get to that later), its directional accuracy.  Goals are aspirational in nature and qualitative in description, and represent the opposite “end state” of your problem statement.  Similar to problem statements, goals help with prioritization, context, and stakeholder alignment.


Outline quantitative success measures to be attained

Success measures, or lack thereof, is the area where I see the most problems.  Companies, stakeholders, and project managers create success measures like, “on time, on budget”, which is a very lazy and undisciplined success measure.  This is because companies spend money and initiate projects for three primary reasons.

  • To save money
  • To make money
  • To reduce risk

In other words, software projects are initiated to help attain business outcomes.  “On time and on budget” are project outcomes, but should not be the primary measure of success for a project, because they are not business outcomes.  Not only that, but “on time and on budget” are only vaguely quantifiable.  What happens if the timeline moves out?  What happens if the budget increases?  You can quickly see how time and budget as a measure of success can quickly get divorced from the business outcomes.

A more concrete measure of success would be “Reduce support calls by 50%.”  There is a direct line between the amount of customer support calls and the overall support cost.  If annual support costs $1,000,000 for a given product, reducing that overhead by 50% creates an additional $500,000 in value.  Its easy to measure, easy to quantify, and easy to calculate the ROI of the project.  In this case, we have a clearly identified business outcome that is specific, quantitative, and directly related to business success.


Moving beyond the triple constraint

To get the most value from project efforts, business stakeholders and product managers need to work with project managers to create lightweight business cases that help everyone understand the problem to be solved, the goals to be achieved, and how we will measure success.

Until Next Time,

Stay Agile, My Friends

PS.  Click here to get more information and examples of problem statements, goals and success measures


There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why The Best Product Managers Delete More Than They Add


The product was falling under its own weight.  It was bloated and didn’t really solve a key problem for the customer.  I talked to the lead product manager about some of the issues with the product, and he relayed that the previous product manager pushed the team to add these features.  He was looking for the “one magical feature” that would make the product take off and make him the hero.  Unfortunately, this approach of “Throw stuff at the wall and see what sticks” is an incredibly poor way to manage a product.  In reality, product managers should deleting more features than they add.



Most features are never used

You can probably think of a common software product you use, and the percentage of its features you use.  Most of us, even power users, use only a small subset of the features of a product.  The Standish Group reports that “only about 20% of a software product’s features are used ‘Always or Often.'”  This means that 80% of the features in the product are never touched.  However those features still need to be supported by the company, debugged by the teams, and pumped up by marketing.  Unfortunately, its the natural state of inertia that as a product is on the market longer, it becomes more and more “feature rich.”  If these features don’t add any value to the user, then they are wasteful.


Effective product management = the art of saying “no”

When a product is first envisoned and built, its easy to manage.  You take an idea and iterate on it with your customers.  However, after a product gets traction, managing it becomes more difficult because there are more outside influences.

  • Certain segments of customers want to see features added to a product that might not be part of the overall strategy.
  • Executive leadership wants to see other features in a product.
  • Competitors are adding features that you need to react to.
  • Product management has their own vision and roadmap.

All these factors combined makes it difficult to decide what goes in and what goes out of a product.  Weak product owners say yes to everything, and simply add it to the list.  Strong product owners stay true to the vision and strategy and say no to most requests, keeping the proposed feature list in line with the overall strategy.  This is, in essence, the root of effective product management.


Removing features creates simple and elegant products

All complex products evolved from simple products that worked well.  Its just along the way, these products lost the original focus, leading to bloat.  Simple products have a much higher chance of inspiring customer passion and delight.  Ask any serious hunter if he would ever use a Swiss Army knife.  He will laugh.  A Swiss Army knife is a tool that fulfills many functions in a mediocre manner, while a knife made for the purpose of skinning animals performs beautifully, even though doesn’t have a nail clipper attachment.  What kind of products do you want to make?  Swiss army knives with nail clipper attachments?  Or highly functional simple, effective tools that customers find indispensable?

To take products back to their simple, elegant, functional roots, remove extra features that don’t add any value and, focus on the core “brand promise”, and create a limited yet necessary feature set.

Until Next Time,

Stay Agile, My Friends

Get 5 Tips to Know When You Should Delete a Requirement

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Your Company Should Create Its Own Agile Process


I was on a phone conversation with a client, and he was relaying a common refrain, “We’re doing everything by the book.  We’re seeing some good results but good golly its painful!”  This client in particular was 3 years into their agile journey, with a well enough established process to understand where the hard edges were for their company, their product, and their culture.

While companies new to agile should follow “by the book” frameworks as closely as possible, companies that are some years into the journey MUST create their own agile process in order to continue to see improvement.


Best practices are only the first step

Most companies seek the advice of experts such as Agile coaches, consultants, and trainers in order to find out what everyone else is doing.  The stuff that works is called a best practice, and consultants are more than welcome to give you those as a blueprint.  What you have to keep in mind is that a best practice is something that has worked well for someone else, and it may or may not work well for you.  To take your adoption to the next level, you have to stop consuming best practices and start producing best practices.  Relentlessly experiment with practices and results.  Based on results, make tweaks to the process to make it work better for your company, creating a new “best practice” for others in your industry.


Your business is unique, your process should be too

There is much value in understanding and incorporating standardized frameworks into how your company operates.  There is more value in deeply p understanding those frameworks and why they work well, then using that to create custom frameworks built for your business.  This creates a competitive advantage for your company because what you create wont be found in any book.  Look to examples from companies like SalesForce and Spotify for examples of how they took basic Agile frameworks, augmented them, and used it to become leaders in their respective industries.


Off the shelf Agile frameworks are purposefully incomplete

When you envision everything that needs to happen for your company to take an idea from concept to cash, then compare that to what the off the shelf frameworks have to offer, you will see gaps.  This is because most Agile frameworks are built to be “purposefully incomplete” in that they couldn’t possibly account for everything that needs to happen for every business type.  The frameworks that attempt to be more comprehensive can come across as bloated and prescriptive.  Start with a lightweight framework such as Scrum, then progressively bolster gaps with customized add ons that fit into the core process.


Beware of pitfalls

While there are upsides to creating your own Agile process, there are also some downsides.

  • Companies try to rush and create a process before they understand the problem to be solved.
  • The often attempt to modify a core framework they don’t yet understand.
  • They attempt to design a perfect process up front.
To avoid some of the same mistakes other companies make when creating an agile process, get my FREE “Custom Agile Processes, Avoiding Mistakes” email mini course.

Tirrell Payton is the principal at Payton Consulting, a San Diego-based boutique consulting firm that helps companies improve their technology capability to match their business ambitions.

Until Next Time,

Stay Agile,  My Friends

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Agile Software Development Is Not Enough and Agile Product Management is the Answer


“Hi, I’m Tirrell.  Thanks a lot for taking the time to chat with me about what you need and how I might be able to help.  So tell me, what is the problem you’re trying to solve?””We want to be more agile”
“Ok, but what does that mean?”
“We want to release software faster and still keep high quality.  We want to improve the productivity of our developers”
“Thanks.  For a second, let’s take a step back from the developers, and talk about the organization… what business goals with ‘going agile’ help you achieve?”
“I never thought of that….”


Software development does not exist in a vacuum

In most organizations, software development is a supporting function for the rest of the business.  The reason the software teams get so much attention when it comes to “measuring productivity” or “becoming more agile” is because software is typically looked at as a cost center.  This means when executive leadership are trying to figure out how to do “more with less”, they look at the areas where the largest amount of money is being spent.  Since engineers and technologists are not cheap, IT and software development is the first place they look to try to improve cost structure or gain efficiencies.

However, the effectiveness, quality, and productivity of a team is more a result of upstream processes and the overall environment than process magic.  In other words, there is no process, agile or otherwise, that will fix problems with your development teams that originate elsewhere in the organization.  While there are actions we can take to improve the teams’ performance, the outcomes will be localized to the extent our problem solving is localized.  System-wide improvements require system-wide changes.


The most neglected piece of the puzzle is effective product management skills

Technologists are an interesting sort; we are fiercely independent, yet we take pride in our work and genuinely want to help solve business problems.  However, most of the issues that manifest in the development teams manifest upstream of the teams.  The product managers are directly upstream of the development teams, so  this places product management squarely in my sights when I am diagnosing development problems in an organization.


Product managers typically suffer from common issues

  • Lack of training.  Most product managers that I have interacted with have had little to no training as product managers.  They may have come from marketing or customer support or occasionally engineering.  While they may be strong in some areas (product design, spec writing, etc), the core skills I would expect from a strong product manager (customer development, business case development, hypothesis driven execution, outcome-oriented thinking) are missing.

    The Fix.  
    Understand where the skill deficit is by comparing your product owners against the Product Owner Core Skills Matrix.  Engage in self-paced just in time practical training, such as “How to Build Your Backlog From Scratch.”
  • Unclear role.  While the title product manager (or product owner) suggests some amount of business or product ownership, product managers often function as glorified business analysts.  Rather than having any ownership of real business outcomes, product managers are put in place to run interference on behalf of the business (document requirements).  This leads to frustrated teams, frustrated stakeholders, and unempowered product managers.The Fix.  Rather than rely on the boilerplate you copied from monster.com, take a fresh look at the role, responsibilities, and expectations of your product managers.  Here is a template to help you.
  • Business objective blindness.  While product managers are supposed to represent the business and their needs, product managers are often kept out of key conversations and don’t have the visibility into the organizations overall strategies, goals, and objectives.  This makes it difficult, if not impossible, to tie product management decisions to overall business objectives.  If product management decisions are not tied to business objectives, what’s the point of having product managers?The Fix.  Invite your product managers to strategic leadership meetings.  This way they can be aligned with the broader business goals.  This means less hand-holding when it comes to articulating problems to be solved, and greater stakeholder satisfaction.


The goal is overall business agility

Your process  that takes an idea from concept to cash is only as strong as its weakest part.  The weakest link is most often not your technology teams, but its the easiest to attack because the costs are visible and the outputs are sub-optimal.  The purpose of agility is to improve business outcomes, and your product managers connect business outcomes to product development process and the software development teams.

As an idea is formulated, improved, developed, released, and monetized, make sure you take a look at the complete cycle.  Where are the bottlenecks?  Where are the miscues?  Where are there opportunities to improve?  The software development aspect is a small part of the end to end value chain.  Make sure you look at your business cases, how you prove ROI, how to run product marketing experiments, and how to engage in effective customer development.

Until Next Time,

Stay Agile, My Friends

Tirrell Payton is the principal at Payton Consulting, a San Diego-based boutique consulting firm that helps companies improve their technology capability to match their business ambitions.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Why Every Company is a Technology Company

The Shocking Truth: Why Every Company Is a Technology Company

When I step foot into a company, one of the first questions I ask leadership is, “What does this company do?” Not because I haven’t done my research on the background of the company, but because I want to hear from them what they think they’re in the business of doing.

The normal ones say, “We’re an ecommerce company” or “We’re an apparel company” or “We’re a fashion brand” or maybe, “We are a biotechnology company.” The smart ones will say something to the effect of, “We’re a technology company that happens to sell health insurance.” In this article I will outline 4 reasons every company should have this same mindset and consider itself a technology company.

Customer expectations are different in a digital-first world

Whether your products are consumer products or you operate business to business, customer expectations are different in this new digital first world. One of the reasons for this is the continuing cross-pollination of consumer technology and business technology.

Back in the day, consumer technology would be considered a “toy” by any serious enterprise technologist. These days, most of the leading edge methods and practices being adopted in enterprise technology come from the consumer world. Whether it be mobile, social or advances in design and interaction, there is a lot more crossover between consumer technology and business technology.

This may seem irrelevant; but you have to remember that your strategic partners, your customers and even your employees operate in this consumer world as well. Therefore, customers expect their services and experiences to be customized and personal. This creates a huge opportunity to create value by meeting their needs, but it will require an updated more flexible execution model. Technology systems will need to be more lean and flexible to fully take advantage of new opportunities.

The competitive landscape continues to accelerate

This has been true for years, but the trap companies sometimes fall into is to think that this is a temporary event, and “once this all blows over” they will be able to go back to “business as usual.”

Acceleration is business as usual, and this means companies will need to be able to rapidly adopt, integrate and deploy new technologies more quickly than their competitors. Everyone looks at the stories of Kodak, Blockbuster and Research in Motion (RIM). When they see the fates of these companies they think, “That could never happen to us.” They said the same thing.

These companies were faced with a changing landscape, but they were so wedded to their current business model they could not see how the changes would affect them. On one hand, they didn’t want to cannibalize their existing business model in favor of something that may have been a temporary fad. On the other hand, these companies were so massive, that changing would require a 5-10 year effort. What do you do in this situation? I generally advise companies to make “1 small bet each quarter, and if that turns out to be a winner, put more resources into it.”

In this new landscape companies have to not only manage current business but also continually probe new models in a systematic way. This means being able to rapidly develop solutions and infrastructure to explore a problem space, then rapidly ramp up if the opportunity turns out to be significant.

Product lifecycles are shortening

With software and technology continuing to change every aspect of how companies operate, the life cycles of products and services are shortening. Products that used to have decade-long refresh timelines now get updated within 12-24 months.

Services like sales, marketing, legal, product development and merchandising have to be agile enough to react in tandem to emerging opportunities. A big part of creating this agility cross-departmentally is having software and technology systems that enhance everyone’s ability to react to change.

Operational capability is tied to technology capability

A big trend in the last decade was outsourcing whereby a company would outsource large parts of their software development and technology implementation to a third party. CFOs everywhere cheered this as a way to unlock enterprise value.

Unfortunately, the honeymoon does not last long, and companies who have sliced their internal technology capabilities to the bone are finding themselves locked into multi-year outsourcing agreements and unable to react quickly to threats and opportunities in the marketplace. These agreements have a defined scope and any change means you have to revisit the contract process, which no one wants to do.

The most successful and highest performing companies have little separation between their business strategy and their technology strategy. In short, they have technology as part of their DNA, and they would NEVER outsource this significant competitive advantage. Companies who realize they are in the technology business can drive speed and innovation by closely aligning their technology leaders with their line of business leaders to co-create solutions.

I work with a lot of companies across industries and all of them have a few things in common:

  • They are in various states of digital transition.
  • They are trying to make sense of rapidly changing demographic trends.
  • Things that were leading edge just 5 years ago no longer work well.

One of the mindsets I work really hard to change is that their transformation is a destination. In fact it’s a never-ending journey of continuous improvement, continuous innovation, and continuous experimentation. Companies who are able to successfully create internal “engines of innovation” are positioned to continually evolve and stay competitive.

Until Next Time
Stay Agile, My Friends

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Run a User Story Workshop

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To AskWorkShop

Running a hands-on user story workshop is one of the most valuable skills a product owner can learn.

7 Steps to a successful User Story Workshop

Step 1:  Form a group of 3-5 people who understand the purpose of the product

3-5 seems to be the magic number. Any less and you might miss some ideas.  Any more, and it slows the process down as well as diminishing returns on the quality of ideas generated.

Let the team to come up with a vision of own dream product. Propose to them that they write high level features for the vision. Clearly explain what you mean by a feature. (Example: Login page for a portal is not a feature). Take each feature and identify the high level requirements on color sticky notes.

Step 2:  Introduce the phrase “EPIC” and tell teams to break features into epics in different color sticky notes

Make a wall map and help the teams to paste the epics exactly below the features. When teams establish features and epics relationship, I would work with them to make team write high level requirements for each epic. Introduce User Story with an example and its intent. Help teams understand various formats of User stories. Convey the importance of identifying User Personas at this stage. Show some examples of splitting user stories. Give few guidelines of dos and don’ts as well as pitfalls and traps when writing user stories.

Step 3:  Start the exercise by asking teams to write high level one liner as requirements for each epic in silence

Each person takes the same colored post-it and silently writes down one user story per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud. If anyone has duplicates, consolidate.

Depending on the size of the epics it can take 3-10 minutes to get all the major user stories. You can watch the body language to see when teams are finished. You can observe that the group goes from huddled in at the beginning to standing/leaning back at the end. It is likely that each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc) which forms the “walking skeleton” of the map. Ask teams to stick all user stories exactly under the related epics. This might be their first ‘aha’ moment for silent brainstorming.

Step 4:  Ask the team to group the sticky notes in silence.

Ask team to move similar things close to each other and dissimilar moved farther. Use silent grouping  because it is faster than grouping them out loud. If duplicates are found, remove them. Groups will form naturally and fairly easily. Once again, body language will help you see when they are done – usually 2-5 minutes.

Step 5:  Introduce acceptance criteria with an example

Help teams write acceptance criteria for individual stories. Now talk about the non-functional requirements. Ask the team to come up with non-functional requirements for the same stories. Arrange all the stories on the wall, and help teams order them, ask them use slice the stories either by date or scope.

Step 6:  Explain sizing of stories using story points and help teams size all the stories

The product owner explains the sizing constraints and facilitates a  story points sizing exercise using planning poker with the team.

Step 7:  Take all the user stories into the first release, then start slicing stories to make them as thin as possible

This is so that the stakeholders get a solid understanding of vertical slices, and so that we will more accurately be able to measure progress.

I see there is lot of value and motivation when team s to come up with their own vision and write down the stories.  The essence of the workshop may be lost when I give pre-cooked user stories to the team. What do you think?





There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

How to Groom, Group, Manage, and Organize User Stories

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To AskOrganize

 Very often, I observe team members conversing in retrospectives, “we have to wait for the requirements to be clarified by the Product Owner, and it is eating up a lot of time and delays our work in the Sprint. In the “good old days” we had requirements specification document which was easily manageable. ”   It is imperative that teams face an uphill task to manage hundreds of stories in their backlog.

I was pondering upon this problem for a while and understood that teams are missing a very important ceremony in the sprint called “Product Backlog Grooming” that would help in grooming, grouping, managing and organizing the user stories.

In short, the product backlog is the single source of requirements in agile, it is an ordered list of requirements, and the majority of the items in this list are the user stories. It needs to be continuously groomed whenever you see a need for it.

Here are few techniques for a team which can make their life easier when dealing with the user stories.

1.  Groom the stories

The teams will have to spend at least ten percent of the time during their iteration, with the product owner to understand the existing stories in terms of clarity, feasibility and fitness in the iteration. If the story is big one, then they need work with the product owner to break it down into smaller chunks, manageable in iteration. Mark the stories as ready for sprint after this meeting, so that there is no back and forth during the iteration.

Remove the stories from the backlog that are no longer needed.

Clarify the stories by elaboration the conditions of satisfaction as required.

Estimate the stories with the best known facts at that time.

Adjust the priority of the story with the permission of the Product Owner. The grooming activity is very much essential to maintaining the product backlog, otherwise it would become unmanageable.

2.  Group the stories

We can group related together under one umbrella that helps us visualize the progress of stories. For example have all reporting templates related stories under ‘reporting’ group, all user management related stories under “user management” group and so on. This grouping of stories is called as “Themes” in agile.

Create high level groups when you start eliciting the requirements and try to group the stories accordingly as and when you add new stories to the backlog.  Some tools like Rally, support a Parent-Child relationship and successor-processor relationship that supports user stories grouping.

3.  Manage the Stories

Managing the stories is very simple. For each story in the backlog, the following attributes that would help in fetching the complete details of the origins of the story, that will make it very easy to track.

  • User Story description
  • Acceptance criteria
  • Parent user story
  • Priority
  • Assumptions
  • Dependencies
  • Assigned to
  • Estimate
  • Team assigned to
  • Group (if this story is grouped )
  • Tasks associated
  • Tests associated
  • Status: Done, In-progress, completed, blocks etc… Impediments etc

Follow the DEEP model, as Mike Cohn calls it. DEEP stands for


Appropriately Highest priority, more detail; lower priority, less, which are broken down into smaller stories for sprints/release.


Growing and evolving overtime; Re-prioritized when items are added /deleted.


The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.


Items that are slated for the next couple of sprints

Organize the stories

Organizing the stories is easy, have team-specific backlogs. Have the stories that are related to your team only in your backlog. Themes are also used to organize stories for releases.  Link your team stories on which you have dependency with other team, that way, you will come to know the status of other linked stories. Have frequent conversations with the Product Owner to prioritize and reprioritize stories.  Help your Product Owner to remove the stories that aren’t belonging to your team.

Imagine your lawn in the back yard, how do you maintain it? It has to be maintained regularly? If not at some point of time it becomes unmanageable, grows haphazardly in all directions, making it difficult to maintain. Similarly, backlog grooming is not a onetime effort.

Do you think you need to consciously water your lawn, trim and manure it, so that it looks healthy?  If you didn’t, imagine what might happen!

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More