Skip to main content

Tag: Competencies

The Project Manager vs. the Business Analyst

Written by Vicki James on . Posted in Articles.

vickyJune6I have a hard time deciding whether “versus” is a good word to compare the two roles. On one hand, the project manager and business analyst should be working collaboratively. On the other hand, the two roles do offer a healthy contest in project related decisions. The issue at hand is that there is a lot of uncertainty about the difference in these roles. The result of this uncertainty is cases where one person plays both roles without enough skills for each, and other cases where the team members do not know who is responsible for what. Hopefully, we can clear this up.

The core of the difference is in the title.

  • The Project Manager manages the project – “The application of knowledge, skills, tools, and techniques to provide activities to meet the project requirements.”
  • The Business Analyst conducts business analysis – “The set of tasks and techniques used to work as a liaison among stakeholders to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to meet its goals.

One source of confusion is the activities in both sets of tasks according to the relevant Body of Knowledge[i]. The intent is that planning and monitoring tasks within the BABOK® are limited to business analysis activities as indicated by the task title.

PMBOK® Task BABOK® Task
4.2 Develop Project Management Plan 2.3 Plan Business Analysis Activities
2.5 Plan Requirements Management
2.6 Manage Business Analysis Performance
4.4 Monitor and Control Project Work 2.6 Manage Business Analysis Performance

5.1 Plan Scope Management
5.2 Collect Requirements

 2.5 Plan Requirements Management Process
3.1-4 Elicitation: Prepare, Conduct, Document, Confirm
4.2 Manage Requirements Traceability
4.4.5.1 Requirements Documentation
5.3 Define Scope 5.4 Define Solution Scope
5.4 Create WBS
5.6 Control Scope		 4.1 Manage Solution Scope
5.4 Define Solution Scope
5.5 Validate Scope 7.5 Validate Solution
8.3 Quality Control (Testing-monitoring and recording results) 7.6 Evaluate Solution Performance(Results analysis and recommendation)
13.1 Identify Stakeholders 2.2 Conduct Stakeholder Analysis
10.1 Plan Communications Management 2.4 Plan Business Analysis Communication
10.2 Manage Communications
10.3 Control Communications		 4.5 Communicate Requirements
2.6 Manage Business Analysis Performance

Stakeholder analysis is one good example of collaboration between project manager and business analyst. The business analyst focuses on stakeholders specific to the requirements and scope of the project. The project manager is looking beyond this to stakeholders whose interest is outside of the project scope. Perhaps the project manager is recording a competitor as a stakeholder to aid in the identification and tracking of potential project risk. The stakeholder analysis is a joint effort. Assign items resulting from the stakeholder analysis to either the project manager or business analyst based on stakeholder interest and influence.

Another point of confusion is in the PMBOK® task of Collecting Requirements. It looks as though the project manager is responsible for collecting requirements. When you look further at the PMBOK® tasks you also find Quality Control, yet we know the project team has members responsible for product quality. The intent of the PMBOK© is that project managers take responsibility to ensure activities for collecting requirements are covered in the project management plan and monitored along with the project. Not the project manager collects the requirements.

Section 5.1 of the CBAP® Handbook does a great job of differentiating “analysis” activities from other activities. Download the CBAP ® handbook from the Certified Business Analysis Professional™ (CBAP®) website for detailed examples of these activities.

Volunteers from both the International Institute of Business Analysis (IIBA®) and Project Management Institute (PMI©) joined in a collaborative project to “facilitate a shared understanding of the roles.”  The conclusion –

Both the PM and BA play leadership roles—the PM for leading the team and delivering the solution and the BA for ensuring that the solution meets the business need and aligns with business and project objectives. And both roles, equally, are required for project success.

You will get decisions based on full information of the impacts to the project and the benefit of the solution when you have both a strong PM and BA playing leadership roles on your projects. The result is a project that brings greatest business value to the organization.

I had the distinct pleasure of joining Elizabeth Larson, PMP, CBAP, CSM, as guest experts on PMChat (a weekly Internet radio show/Twitter web chat) to discuss the BA and PM roles on June 1, 2012.

Don’t forget to leave your comments below.

[i] Project Management Body of Knowledge (PMBOK® Guide) 5th Edition
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0

References

Get Support from the Grumpy Old Man

Written by Angela Wick on . Posted in Articles. 1 Comment on Get Support from the Grumpy Old Man

wick Nov12How would you “caricaturize” your organization?

We’ve all been to a fair or festival and watched caricature artists draw distorted people with giant cartoon-like heads and exaggerated features.
If you made a caricature of your organization, what would it look like?

Here are two extreme organizational caricatures:

Grumpy Old Man

  • Picture Andy Rooney’s bushy eyebrows, a cigar, a scowl and an iron fist.
  • This organization is set in its ways, not open to change, fixed in routine, dictatorial, risk averse, backward-thinking—what worked in the past will continue to work.
  • BAs in this environment might have strict procedures, many required templates, limited flexibility and a clearly-defined hierarchy.

Fearless Toddler

  • Picture a wide-eyed, smiling and wobbly 12-month old, touching and tasting everything without concern for consequences. Each day is a series of experiments with repeating cycles of attempts, failures, learning and trying again.
  • This organization values experimentation, rewards risk, and is forward-thinking—what’s next and what’s new.
  • BAs in this environment might be required to define their own roles and procedures, with few internal rules and minimal structure. Priorities might change frequently.

Which caricature describes your organization?

How does that impact your ability to get the support you need to try new tools and techniques?

The Fearless Toddler would welcome your experimentation, but how do you get support from the Grumpy Old Man?

Here are a few ways to help your Grumpy Old Man open up to new ideas:

  1. Cross-Team Training

    In many organizations, stakeholders don’t really understand the BA role. The right team workshop can help everyone appreciate possibilities and benefits of effective elicitation, analysis, issue resolution and prioritization processes

    This strategy exponentially increases the value of training because resistance is minimized and BAs have the support they need to help their organization move forward.

    Something magical happens when BAs, PMs, QAs and SMEs learn new skills together. At one of my client sites, BAs were happily overwhelmed when their business managers pushed them to try four new techniques just days after they all took BA training together.

  2. Take Baby Steps

    Start small. Figure out a way to apply new ideas in phases. Find a way to fit new techniques into current procedures. Start with techniques that are a simple expansion of current practices.

    If you have a new facilitation technique you want to try, practice it in a low risk meeting with a small group of friendly stakeholders. Ask for honest feedback.

  3. Ask permission

    Many people will tell you “it’s better to ask forgiveness later than ask permission now.” However, in some organizations it is not appropriate to try new techniques and tools without approval from a leadership team. In this case, you may need to follow a formal process to introduce new ideas.

    Even in less-structured organizations, a simple request process might maximize cooperation:

    1. Choose a new tool or technique.
    2. Submit a brief proposal to key members of your organization.
    3. Describe the benefits of the technique, your implementation plan and how you will report the results.
    4. Make sure you include any benefits that save time, reduce cost or minimize risk.
  4. Just do it! Take the risk and try something new.
    1. Prepare well, be confident and be willing to fail.
    2. Set expectations. Let people know that you plan to try something new.
    3. Use time wisely and give stakeholders a way to provide feedback.

    Whether you succeed or fail, you’ll learn something valuable about yourself and about your organization. Maybe you’ll learn that your organization is not as grumpy and old as you thought or you’ll learn the old process worked better. You might find support and flexibility or you might find a brick wall. Use your findings to inform future choices and experiments.

  5. Share expert opinions

    Sometimes you need a third party to help you advocate for change. You could hire a team of consultants. But if your budget is limited, find expert resources online. Find articles, videos, and other resources.
  6. Build your base

    Float new ideas, one person at a time, during lunch, after meetings, at happy hour, in the elevator and by the coffee pot. You will find support.

How do you get your stakeholders wide-eyed and smiling? How do you build support for new tools and techniques in your organization? Please leave your comments below.

Don’t forget to leave your comments below.

Effective Requirements Planning

Written by Kathleen O'Brien on . Posted in Articles.

Why do I need to plan?

When I think of requirements, a picture of Mr. Potato Head comes to mind. There are a bunch of pieces and an infinite number of ways to put the pieces together. You need an approach for building the requirements specification.

obrien img1 nov12
This same principle applies to requirement development. If you don’t plan before you jump into the requirements development, you may experience the following consequences:
  • Ineffective BA techniques
  • Inability to respond to project evolution in an organized manner
  • Missed timelines
  • Forgotten sections of requirements
  • Lack of alignment between the capacity of the team and the schedule

As Dwight D. Eisenhower said “In preparing for battle, I have always found that plans are useless but planning is indispensable”. Additionally, a requirements effort is a journey that you as the BA are leading a team along. If you don’t have a solid plan how can you communicate a clear vision to your team and gain their commitment?

In the BABOK, “Plan Business Analysis Approach” is the 1st task in the 1st knowledge area “Business Analysis Planning and Monitoring”. This highlighting that this task is the place to start when developing requirements. But so often we have no time to plan upfront. Our PM comes to us and says I need the requirements done in 2 weeks. As good team players we get them done but then pay the price by constantly changing the requirements since they were not done right. We all know the cost of poor requirements to IT organizations. Per the Standish Group Reports1, only 32% of IT projects are successful and 20% of the features / functions delivered are used regularly. Multiple studies have traced these IT failures to poor requirements definition.

Therefore, I am proposing we as BAs need to embrace the need to plan and to sell this to our PMs. I hope this article give you the background you need to develop a solid Requirements Approach and the ammunition to sell this to your PM.

A Requirements Approach allows you as a BA to:

  • Select the best methodologies and techniques for requirements development based on the needs of the project and stakeholders
  • Develop consistent requirements
  • Gain commitments from all stakeholders to provide necessary time and input
  • Respond to project evolution in an organized manner
  • Clearly communicate BA commitments and establish a BA contract with IT and business stakeholders

But it is not all about the BA benefiting! Developing a solid Requirements Approach benefits the entire team. For Project Manager, the Requirements Approach can be the basis for developing detailed, accurate project plans. For Business Partners, the Requirements Approach provides visibility which sets clear expectations and fosters a collaborative environment. For the QA professionals on the team, the Requirements Approach provides insight into the requirement deliverables so the testing efforts can be proactively planned at the start of the project.

The Lead Business Analyst develops the approach and collaborated with the other BAs on the project, the PM and the business partners to refine the approach so it meets everyone’s needs and incorporates the team’s diverse perspectives. The Requirements Approach should be an official project deliverable but does not have to be a 100 page document. A short document or a PowerPoint is sufficient. The goal is to think through the approach and get team buy-in, therefore right-size the deliverable to meet this goal.

How do I create a Requirements Approach?

A Requirements Approach is a roadmap for the developing requirements for a project. The Roadmap should cover all phases of requirements development:

Planning – Develop a plan for gathering and communicating requirements.
Eliciting and Validating – Extract information to prepare to document the requirements.
Documenting – Collate, author, and publish requirements to stakeholders.
Approving – Secure acceptance of the requirements from the stakeholders.

The following components should be defined for the Planning phase in the Requirements Approach:

  • Scope – Clearly define what is in scope for the requirements development effort and enumerate out of scope items. Note, this is not the scope of the project which should be clearly outlined in a different document.
  • Assumptions, Dependencies and Risks – List all things that effect or constrain the requirements development effort.
  • Standards – Define the industry, company and divisional standards guiding this effort.
  • Requirements Development Team – Define roles (both IT and business) and individuals that fill these roles.
  • Requirements Development Communication Plan – Define communications to be sent regarding requirements development to keep key stakeholders informed on progress. The key stakeholders are those defined during stakeholder analysis.
  • Requirements Development Project Plan – Key factors that affect the requirements development project plan such as BA resource constraints along with high level timelines and resources for the requirements development effort. A link to the requirements development project plan is also included.
  • Requirements Change Management – Define how changes to the requirements will be handled.
  • Methodology – This is the core of the requirements approach since it clearly defines how the requirements development effort will be structured.

Let’s discuss the methodology component in more detail. In the methodology component, the following should be defined:

  • SDLC methodology (Agile, Waterfall, Iterative, etc.)
  • Types of requirements to be developed (Business, System, Analytics, Integration, etc.)
  • Steps for defining each type of requirement
  • Tools, techniques and details for each step

To help make this more real, here is an example of a Methodology section from a real life project:

obrien img2 Nov12

The Planning section is the bulk of the Requirements Approach. The table below shows the components for the other 3 phases:
obrien img3 Nov12
That covers the components of a Requirements Approach. Just remember, this is not a once and done artifact! Get your initial approach defined but be ready to continuously refine as the needs of the project and team evolve.

Finally, use your tools to enforce your requirements approach:

obrien img4 Nov12
To make getting started easier, I created a template.

Good luck with planning a successful requirements development effort.

Don’t forget to leave your comments below.

Sources:
1. Chaos Study 2009 – www1.standishgroup.com/index.php
2. BABOK v2.0 2009 – http://www.iiba.org/BABOK-Guide.aspx

Resources for Related Topics:
– Stakeholder Analysis – BABOK v2.0 Section 2.2
– Communication Plan – BABOK v2.0 Section 2.4
– Work Breakdown Structure – BABOK v2.0 Section 2.3.4.4

Filling your Toolbox: Factors that Influence BA Skill Development

Written by Angela Wick on . Posted in Articles.

wick Sept17Everyone has a career toolbox—a collection of tips, tricks, skills and techniques. The tools accumulate over time:

  • Some tools come with the toolbox: innate gifts, talents.
  • We purchase tools: training, degrees, memberships in professional organizations.
  • Other people buy or donate tools: employers offer training, mentors, experience.
  • If we are inventive, we build our own tools.

Most BAs have a few standard tools they use frequently, but many of the tools just lay in the toolbox, unused. We don’t schedule time to check inventory, get rid of old tools, determine what is missing or anticipate future needs. We don’t fill our toolboxes efficiently or effectively.

BAs need to fill their tool boxes, but they shouldn’t fill them passively—just accepting the opportunities presented. Instead, BAs should choose, with intention, which skills they add. 

Three factors influence this purpose-driven approach to BA skill development:

  • Awareness
  • Desire
  • Support

If individuals and organizations cultivate these attributes, BA skill development efforts will be effective, efficient and will provide lasting value. 

Awareness 

BAs can’t develop skills effectively unless they understand the strength and value of their current capabilities. 

So, what’s the current state of your BA toolbox?

  • Do you know your strengths and weaknesses?
  • Which competencies have you mastered?
  • Which competencies are missing?
  • Which skills will future projects require?
  • Which skills will be required for career advancement?
  • Which skills are valued by your organization?
  • What business/technology/cultural trends will influence the value of certain skills?

Essentially, you need to be aware of your own capabilities, but also understand how external entities value your skills. 

Here are a few ways to cultivate awareness:

  1. Complete a BA skill assessment. You can do this informally by creating a comprehensive list of BA skills from sources like the BABOK and then rating your mastery of each skill on a scale of 1-5 or you can use the IIBA’s competency assessment tool. 
  2. Track stakeholder feedback. Make note of verbal and non-verbal feedback you receive from stakeholders. Find patterns and trends that indicate your strengths and weaknesses.
  3. Maximize your annual evaluation process. For those lucky enough to receive meaningful performance reviews—take advantage of the opportunity—get honest feedback from your manager.
    • Ask about your reputation.
    • Define skill-related goals.
    • Suggest new skills that would benefit the organization.
  4. Evaluate training provided by your organization.
    • Why is the training being offered?
    • How can you apply the skills in your current environment?
    • What are the expectations upon completing training?
  5. Compare yourself to others. Choose a few BAs you admire or consider successful. Identify their strengths. Determine if developing similar skills would help you achieve your goals.
  6. Review industry job descriptions:
    • Which skills appeal to you?
    • Which skills seem to be in highest demand?
    • Do you have all of the skills required for your dream position?

Desire

Since the BA role centers on facilitating change in an organization, BAs need to be willing to change themselves too. BAs can’t develop skills effectively without the desire to learn, grow, experiment or improve. Without desire, BA skills get old and begin to lose value.

A BA with desire:

  • Advocates for training, mentoring or experiences that will bring value to the BA role and the organization.
  • Takes risks by experimenting with new skills and techniques.
  • Practices new skills until they see results—do not just try skills once with ho-hum results and not try again.

An organization wishing to cultivate desire:

  • Establishes a vision for the BA team.
  • Identifies and communicates the skill set needed to achieve the vision.
  • Communicates expected results.
  • Provides answers to: “How will new skills address my pain and challenges in my job?”

Support

Some BAs have awareness and desire, but find skill development limited by the leaders in their organizations. 

Many BAs report to technical or business managers that do not have a clear understanding of the BA role. BAs in this position often struggle to obtain meaningful skill development opportunities.

In organizations where skill development is a priority, this is what you might experience:

  • Leaders encouraging the use of new tools and techniques.
  • Leaders modeling desired behavior by experimenting with new skills.
  • Stakeholders, team members, and peers accepting change and encouraging experimentation.
  • Skill development plans with flexibility to accommodate learning styles.
  • A strong team atmosphere.
  • A healthy respect for the lessons-learned from failure.

Can you think of other factors influence BA skill development? Please leave your comments below.

Don’t forget to leave your comments below.

User Stories Ready, Set, GO!

Written by Robert Galen on . Posted in Articles.

galen aug20 1Introduction

Have you ever entered a Sprint taking on a User Story that you later regretted? For example:

  • One that you should have broken down a wee bit more?
  • Or one where the team had not a “snowball’s clue” how to technically implement?
  • Or one where the value wasn’t clear from a business perspective?
  • Or one where the estimate and the reality were not equal?
  • Or one that, when you got it “Done”, you weren’t quite sure how to determine that it was done?

I’m guessing, of course you have. I encounter these scenes in teams I’m coaching all the time. And truth be told, it’s not a terrible event. Teams make mistakes…all the time. And they usually learn from them.

The real problem, from my perspective, is with the teams that continue to do this sprint over sprint over sprint. Yes, the dynamics slightly change, but the end result is the same.

The team is taking on User Stories that are truly not READY for the Sprint!

So the question is: what can be done to prevent it? Is there a technique that will prevent this from happening or are these teams doomed to keep repeating their mistakes? I’m glad you asked.

The Flip Side of Definition-of-Done

I hope everyone is familiar with the terminology Definition-of-Done (DoD)or Done-Ness from an agile methods perspective. It’s a common phrase and incredibly important to agile team health and maturity. It’s essentially exit criteria, if you will, for the teams sprint work.

At a User Story level, it’s common to refer to each story’s acceptance criteria as the done-ness check for story completeness. At a sprint complete level, it’s common to refer to the Sprint Goal as the checkpoint for what the team was trying to deliver. And done-ness also permeates into how each team member does their work. For example, are code reviews part of a teams’ done-ness criteria? If so, then they will consistently plan for and execute code reviews as a part of developing and delivering each story.

So the Definition-of-Done is an “exit criteria”; one that determines condition of completeness for work being delivered. But there is another criterion that is useful in agile teams at the “other end” of the workflow—the delivery end. Let’s call it Definition of Ready (DoR) or “Readiness Criteria”. In this case, it’s associated with each individual work item that flows through an agile team.

If you’re practicing Scrum, then it would be at the Product Backlog Item (PBI) level. If you’re an XP team or leveraging User Stories, then it would be for each story that enters a team. The readiness criteria would be a clear definition of what connotes a User Story or PBI that is “ready” for execution within the iteration or Sprint. 

It turns out that preventing ill-defined stories (or work) from entering each Sprint in the first place, is an incredibly healthy way of warding off the challenges I described in the introduction. But let’s explore readiness in a bit more detail.

Ways of Looking At It

The 4–R’s

Tony Shawver is a coach and consultant working for Matrix Resources in Atlanta. In this blog entry, he described a method or approach for defining “The 4-R’s” of story readiness:

  1. Raw – This is an “initial placeholder” User Story which generally only includes the title and possibly a supporting sentence or two. It allows the Product Owner or stakeholder to enter the general thought for later refinement.
  2. Refined – In this state, the Story has been refined by the Product Owner or stakeholder and includes: a) an appropriate title, b) an adequate description, and c) acceptance criteria.
  3. Reviewed – In this state, the Story has been reviewed by one or more team members. The team members have vetted the general requirement and posed needed questions/clarifications back to the Product Owner/stakeholder for response.
  4. Ready – The content of the Story is complete, all questions/clarifications have been made, and all acceptance criteria are adequate for development and testing. This Story is now ready to be taken into a Sprint planning (or pre-planning) session.

Stories and work on the teams Product Backlog is moved through these ‘phases’ as a way of preparing each story for execution. Clearly a story could move from Raw to Ready very quickly. Let’s say it was a small, relatively straight-forward story that was clearly understood by the team. A few questions and some writing later, the story should be “good enough” for execution. Conversely, a complex or technically challenging story might take many iterative discussions to move it into a Ready state.

Ultimately, the team is the final arbiter for whether a story is ready or not—based on their understanding and ability to envision executing the story without major impediments.

Roman Pichler

Roman Pichler wrote a book related to the Scrum Product Owner role. Since he and I are competitive authors, I try to quote him as infrequently as possible. But he shared a blog post that focuses on this topic and I thought it valuable to share. Here’s an excerpt:

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artifacts are simply attached to the story, as the picture below illustrates…

Roman brings up a couple of important points in your definition of readiness:

  1. Operational Constraints – define any and all constraints that the story will have related to releasing it. I like the notion of viewing agile work from “concept to cash”. I.e., it’s not ‘done’ until it’s in production and being used by your customers. So, from that perspective, make sure that all of these constraints are visible as part of the story.
  2. Sufficient Pre-work Design – another important balancing act agile teams have is guarding against BDUF (Big Design Up Front), while still doing just enough design to fully understand the scope and integration of a feature. This is particularly important when a team is working on cross-team features or on technically complex work. You can see design being needed at a UX level, but also in general.

Thanks to Roman for helping to “flesh out” a healthy alternative view to readiness.

Another way of Describing Ready

I personally like a checklist approach for describing teams’ readiness criteria for work. Here’s an example of the sorts of checks that I’ve seen prove valuable for teams to leverage when maturing their stories:

  • The Story is well-written; and has a minimum of 5 Acceptance Tests defined.
  • The Story has been sized to fit the teams velocity & sprint length; for example somewhere between 1-13 points.
  • The team has vetted the Story in several grooming sessions—its scope & nature is well understood.
  • The team has the requisite skill-set & experience to implement the Story and deliver it to meet the organizational and teams’ Definition-of-Done.
  • If required, the Story had a research-spike to explore (and refine) it’s architecture and design implications; or to explore the testability challenges associated with it.
  • The Story describes end-to-end behavior in the system.
  • The team understands how to approach the testing of the Stories’ functional and non-functional aspects.
  • Any dependencies to other Stories and/or teams have been “connected” so that the Story is synchronized and deliverable as part of the “greater whole”.
  • The Story aligns with the Sprints’ Goal and is cleanly demonstrable.

So there are no distinct phases in this case. A new User Story simply has to meet all of the above checks in order for it to be considered ‘ready’ for execution. How each story gets ready is up to the Product Owner for each Product Backlog collaborating with their team. It could take one or fifty steps to get there. It could be fast or slow. But working together, they decide on how to shepherd a story towards execution readiness.

galen aug20 2Beyond Scrum, you can see how this technique would be useful. If you’re implementing Kanban, than readiness criteria is the definition work required for something to enter the “ready queue” on your Kanban Board. 

Relationship to Backlog Grooming

So you might be asking yourself the question, how does a User Story achieve done-ness? From my perspective, it’s part of ongoing, real-time Backlog Grooming or Backlog Maintenance that a team takes on as a natural part of maturing their Backlog.

Regular grooming meetings provides a venue for these discussions, and as a part of grooming, I like a 4-phased approach to reviewing stories. What Sprint each story is planned for delivery is a leading indicator for when it’s grooming needs to be completed by. I call each phase a “different point of view or lens” for looking at the Backlog and what’s moving towards execution & delivery. For example:

  • Lens One: The Very Next Sprint – These Stories would need to meet the readiness criteria. Using a 4-R’s approach, these are READY.
  • Lens Two: 2-3 Sprints in the Future – These Stories are quite mature. If they needed design work or spike work, it’s been done (or minimally planned). Using a 4-R’s approach, these are REFINED to REVIEWED.
  • Lens Three: The Next “Release” – These Stories our in the future. Typically, they’re far from ready, but the teams’ responsibility is to “get them ready”. Often early activity surrounds estimation and removing technical risk or ambiguity—so that the Product Owner can “plan for” and commit to the release. Using a 4-R’s approach, these are mostly being REFINED.
  • Lens Four: The Far Flung Future (Epics) – These Stories are future context based. They mostly help the team to understand where they “might be going” in their development efforts. High level sizing’s and ROI determination is a large part of the work here. Using a 4-R’s approach, these are mostly RAW to slightly REFINED.

I sometimes refer to grooming as a “conveyer belt” moving User Stories close and closer to execution. The concept of Definition-of-Readiness nicely complements this analogy and strategy.

Wrapping Up

I often use the term guardrails as a synonym for DoD. These are constraints that are defined for the team to help “keep them on the road” to agile maturity and delivery. I would liken the Defintion-of-Readiness (DoR) or readiness criteria as another guardrail for the team. These are not typically part of the “Core Scrum” definition. However, like User Stories and Backlog Grooming, they are incredibly useful practices for many teams.

If you go back to the introduction, those struggling teams have lost sight of how to properly pre-define their work. Establishing a Definition-of-Ready for a while should help them improve. Once that becomes a part of their culture and DNA, then it may not even be worth definition going forward, as it’s served its purpose.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

References