Using the tabindex attribute

https://www.paciellogroup.com/blog/2014/08/using-the-tabindex-attribute/

 

The HTML tabindex attribute is used to manage keyboard focus. Used wisely, it can effectively handle focus within web widgets. Used unwisely however, the tabindex attribute can destroy the usability of web content for keyboard users.

The tabindex attribute indicates that an element can be focused on, and determines how that focus is handled. It takes an integer (whole number) as a value, and the resulting keyboard interaction varies depending on whether the integer is positive, negative or 0.

To understand why the tabindex attribute has such a powerful effect on usability, it’s necessary to know something of the way keyboard interaction works. A keyboard user will typically move through web content using the tab key, moving from one focusable element to the next in sequential order.

Certain interactive HTML elements like links and form controls are focusable by default. When they’re included in a web page, their sequential order is determined by the source order of the HTML.


<label for="username">Username:</label>
<input type="text" id="username">

<label for="password">Password:</label>
<input type="password" id="password">

<input type="submit" value="Log in">

A keyboard user would tab first to the username field, then the password field, and finally to the log in button. All three elements take focus by default, and they’re accessed in the order that they appear in the source code. In other words, there’s no need to explicitly set the tabindexbecause it’s all handled effortlessly in the browser.

tabindex=0

When tabindex is set to 0, the element is inserted into the tab order based on its location in the source code. If the element is focusable by default there’s no need to use tabindex at all, but if you’re repurposing an element like a <span> or <div>, then tabindex=0 is the natural way to include it in the tab order.

It’s worth mentioning at this point that it’s easier to use a focusable HTML element wherever possible. For example, when you choose to use a <button> or <input type="checkbox">, keyboard focus and keyboard interaction are handled automatically by the browser. When you repurpose other elements to create custom widgets, you’ll need to provide keyboard focus and interaction support manually.

tabindex=-1

When tabindex is set to a negative integer like -1, it becomes programmatically focusable but it isn’t included in the tab order. In other words, it can’t be reached by someone using the tab key to navigate through content, but it can be focused on with scripting.

An example is moving focus to a summary of errors returned by a form. The summary would typically be located at the start of the form, so you want to draw the attention of screen reader/magnifier users to it, and to position all keyboard-only users at the start of the form so they can begin correcting any errors. You don’t want the error summary itself to be included in the tab order of the page though.


<div role="group" id="errorSummary" aria-labelledby="errorSummaryHeading" tabindex="-1">
<h2 id="errorSummaryHeading">Your information contains three errors</h2>
<ul>
...
</ul>
</div>

tabindex=1+

It’s when tabindex is set to a positive integer that things get problematic. It imposes a tab order on the content that bears no resemblance to the expected tab order.


<label for="username">Username:</label>
<input type="text" id="username" tabindex="3">

<label for="password">Password:</label>
<input type="password" id="password" tabindex="1">

<input type="submit" value="Log in" tabindex="2">

In this example the visual presentation of the form would be as expected: Username and password fields, followed by the log in button. The tab order would make no sense at all however. Focus would move first to the password field, then the log in button, and finally to the username field.

Things get worse when you realise that the password field would be the first focusable element on the page containing the form. It doesn’t matter how many focusable elements appear in the source order/visual presentation before the password field, the tabindex of 1 means it’ll be the first element to receive focus on the page.

The tabindex attribute is versatile, and it has the capacity to improve or destroy usability for keyboard-only users. When you think about using the tabindex attribute, keep these things in mind:

  • Use tabindex=0 to include an element in the natural tab order of the content, but remember that an element that is focusable by default may be an easier option than a custom control
  • Use tabindex=-1 to give an element programmatic focus, but exclude it from the tab order of the content
  • Avoid using tabindex=1+.

Further reading

Translations

About Léonie Watson

Léonie is Communications director and Principal engineer at TPG, co-chair of the W3C Web Platform Working Group working on HTML and Web Components, writer for Smashing magazine, SitePoint.com and Net magazine, and regular conference speaker.

Advertisements

Set focus on first invalid input in AngularJs form

https://stackoverflow.com/questions/20365121/set-focus-on-first-invalid-input-in-angularjs-form

 

Ok, so the answer was simpler than I thought.

All I needed was a directive to put on the form itself, with an event handler looking for the submit event. This can then traverse the DOM looking for the first element that has the .ng-invalid class on it.

Example using jQLite:

myApp.directive('accessibleForm', function () {
    return {
        restrict: 'A',
        link: function (scope, elem) {

            // set up event handler on the form element
            elem.on('submit', function () {

                // find the first invalid element
                var firstInvalid = elem[0].querySelector('.ng-invalid');

                // if we find one, set focus
                if (firstInvalid) {
                    firstInvalid.focus();
                }
            });
        }
    };
});

The example here uses an Attribute directive, you could expand the example to have this be an element directive (restrict: ‘E’) and include a template that converts this to a . This is however a personal preference.

A/B Testing

https://www.optimizely.com/ab-testing/

WHAT IS A/B TESTING?

A/B testing (also known as split testing or bucket testing) is a method of comparing two versions of a webpage or app against each other to determine which one performs better. AB testing is essentially an experiment where two or more variants of a page are shown to users at random, and statistical analysis is used to determine which variation performs better for a given conversion goal.

What is A/B testing

Running an AB test that directly compares a variation against a current experience lets you ask focused questions about changes to your website or app, and then collect data about the impact of that change.

Testing takes the guesswork out of website optimization and enables data-informed decisions that shift business conversations from “we think” to “we know.” By measuring the impact that changes have on your metrics, you can ensure that every change produces positive results.

HOW A/B TESTING WORKS

In an A/B test, you take a webpage or app screen and modify it to create a second version of the same page. This change can be as simple as a single headline or button, or be a complete redesign of the page. Then, half of your traffic is shown the original version of the page (known as the control) and half are shown the modified version of the page (the variation).

A/B testing Optimizely

As visitors are served either the control or variation, their engagement with each experience is measured and collected in an analytics dashboard and analyzed through a statistical engine. You can then determine whether changing the experience had a positive, negative, or no effect on visitor behavior.

Control vs Variation

WHY YOU SHOULD A/B TEST

A/B testing allows individuals, teams, and companies to make careful changes to their user experiences while collecting data on the results. This allows them to construct hypotheses, and to learn better why certain elements of their experiences impact user behavior. In another way, they can be proven wrong—their opinion about the best experience for a given goal can be proven wrong through an A/B test.

More than just answering a one-off question or settling a disagreement, AB testing can be used consistently to continually improve a given experience, improving a single goal like conversion rate over time.

For instance, a B2B technology company may want to improve their sales lead quality and volume from campaign landing pages. In order to achieve that goal, the team would try A/B testing changes to the headline, visual imagery, form fields, call to action, and overall layout of the page.

Testing one change at a time helps them pinpoint which changes had an effect on their visitors’ behavior, and which ones did not. Over time, they can combine the effect of multiple winning changes from experiments to demonstrate the measurable improvement of the new experience over the old one.

A/B Testing Results Over Time

This method of introducing changes to a user experience also allows the experience to be optimized for a desired outcome, and can make crucial steps in a marketing campaign more effective.

By testing ad copy, marketers can learn which version attracts more clicks. By testing the subsequent landing page, they can learn which layout converts visitors to customers best. The overall spend on a marketing campaign can actually be decreased if the elements of each step work as efficiently as possible to acquire new customers.

A/B Testing Conversion Funnel

A/B testing can also be used by product developers and designers to demonstrate the impact of new features or changes to a user experience. Product onboarding, user engagement, modals, and in-product experiences can all be optimized with A/B testing, so long as the goals are clearly defined and you have a clear hypothesis.

A/B TESTING PROCESS

The following is an A/B testing framework you can use to start running tests:

  • Collect Data: Your analytics will often provide insight into where you can begin optimizing. It helps to begin with high traffic areas of your site or app, as that will allow you to gather data faster. Look for pages with low conversion rates or high drop-off rates that can be improved.
  • Identify Goals: Your conversion goals are the metrics that you are using to determine whether or not the variation is more successful than the original version. Goals can be anything from clicking a button or link to product purchases and e-mail signups.
  • Generate Hypothesis: Once you’ve identified a goal you can begin generating A/B testing ideas and hypotheses for why you think they will be better than the current version. Once you have a list of ideas, prioritize them in terms of expected impact and difficulty of implementation.
  • Create Variations: Using your A/B testing software (like Optimizely), make the desired changes to an element of your website or mobile app experience. This might be changing the color of a button, swapping the order of elements on the page, hiding navigation elements, or something entirely custom. Many leading A/B testing tools have a visual editor that will make these changes easy. Make sure to QA your experiment to make sure it works as expected.
  • Run Experiment: Kick off your experiment and wait for visitors to participate! At this point, visitors to your site or app will be randomly assigned to either the control or variation of your experience. Their interaction with each experience is measured, counted, and compared to determine how each performs.
  • Analyze Results: Once your experiment is complete, it’s time to analyze the results. Your A/B testing software will present the data from the experiment and show you the difference between how the two versions of your page performed, and whether there is a statistically significant difference.

If your variation is a winner, congratulations! See if you can apply learnings from the experiment on other pages of your site and continue iterating on the experiment to improve your results. If your experiment generates a negative result or no result, don’t fret. Use the experiment as a learning experience and generate new hypothesis that you can test.

A/B testing Process

Whatever your experiment’s outcome, use your experience to inform future tests and continually iterate on optimizing your app or site’s experience.

A/B TESTING & SEO

Google permits and encourages A/B testing and has stated that performing an A/B or multivariate test poses no inherent risk to your website’s search rank. However, it is possible to jeopardize your search rank by abusing an A/B testing tool for purposes such as cloaking. Google has articulated some best practices to ensure that this doesn’t happen:

  • No Cloaking – Cloaking is the practice of showing search engines different content than a typical visitor would see. Cloaking can result in your site being demoted or even removed from the search results. To prevent cloaking, do not abuse visitor segmentation to display different content to Googlebot based on user-agent or IP address.
  • Use rel=”canonical” – If you run a split test with multiple URLs, you should use the rel=”canonical” attribute to point the variations back to the original version of the page. Doing so will help prevent Googlebot from getting confused by multiple versions of the same page.
  • Use 302 Redirects Instead Of 301s – If you run a test that redirect the original URL to a variation URL, use a 302 (temporary) redirect vs a 301 (permanent) redirect. This tells search engines such as Google that the redirect is temporary, and that they should keep the original URL indexed rather than the test URL.
  • Run Experiments Only As Long As Necessary – Running tests for longer than necessary, especially if you are serving one variation of your page to a large percentage of users, can be seen as an attempt to deceive search engines. Google recommends updating your site and removing all test variations your site as soon as a test concludes and avoid running tests unnecessarily long.

For more information on AB testing and SEO, see our Knowledge Base article on how A/B testing impacts SEO.

A/B TESTING IDEAS

The following is a list of ideas to get you started with testing. A/B testing best practices for what to test can vary by industry, so the ideas are broken up by vertical:

Media Companies

A media company might want to increase readership, increase the amount of time readers spend on their site, and amplify their articles with social sharing. To achieve these goals, they might test variations on:

  • Email sign-up modals
  • Recommended content
  • Social sharing buttons
Travel Companies

A travel company may want to increase the number of successful bookings are completed on their website or mobile app, or may want to increase revenue from ancillary purchases. To improve these metrics, they may test variations of:

  • Homepage search modals
  • Search results page
  • Ancillary product presentation
Ecommerce Companies

An e-commerce company might want to increase the number of completed checkouts, the average order value, or increase holiday sales. To accomplish this, they may A/B test:

  • Homepage promotions
  • Navigation elements
  • Checkout funnel components
Technology Companies

A technology company might want to increase the number of high-quality leads for their sales team, increase the number of free trial users, or attract a specific type of buyer. They might test:

  • Lead form components
  • Free trial signup flow
  • Homepage messaging and call-to-action

A/B TESTING EXAMPLES

These A/B testing examples show the types of results the world’s most innovative companies have seen through A/B testing with Optimizely:

Disocvery conversion rate increase
Discovery A/B tested the components of their video player to engage with their TV show ‘super fan.’ The result? A 6% increase in video engagement.
Sony conversion rate increase
Sony A/B tested variations of its homepage checkout page layout to increase purchases by 20%.
comScore conversion rate increase
ComScore A/B tested logos and testimonials to increase social proof on a product landing page and increased leads generated by 69%.
Secret Escapes conversion rate increase
Secret Escapes tested variations of their mobile signup pages, doubling conversion rates and increasing lifetime value.

Tips for Effective Backlog Grooming

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.

 

Updated for the 2013 Scrum Guide

Professionally graphic designed PDF version of this article here(Creative Commons):

 

Executive Summary

In a previous article, I discuss the answer to the question of What does Product Backlog Refinement Look Like?. In this article, I discuss some tips for how to do effective Product Backlog Refinement. The primary benefits of backlog refinement are increased productivity, increased understanding/quality, and prevention of delays due to unknowns. Backlog refinement can be a little difficult at first when getting started, but the benefits are large and they appear very quickly, usually after just a couple of Sprints of doing it.

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.

Some Assumptions of this article

  • There are several kinds of Product Backlog refinement, but in this article, I will focus almost exclusively on Weekly Team Product Backlog Refinement, except as otherwise noted.
  • I use Scrum terminology and a 2 week Sprint cycle in this article, but you can translate these concepts to other software approaches and iteration lengths.
  • I will use the more generic Product Backlog Item(PBI) term here, except where I make special mention of User Stories. Pretty much everything in this article also applies to User Stories.
  • Synonyms for Product Backlog Refinement: backlog grooming, sprint preview meeting, user story grooming, detailing user stories, user story conversations, etc
  • Any time I mention “backlog”, “backlog item” or “item” in this article, I’m referring to the Product Backlog and *not* referring to the Sprint Backlog.

 

Tips for Effective Backlog Refinement

In my tips articles, I try to describe highly effective ways to fulfill the Scrum framework. The Scrum framework intentionally leaves holes that are opportunities for teams to fulfill the framework in the way that is best for a particular team’s circumstances. The Scrum Guide defines the Scrum framework, and my tips are in no way meant to define or re-define Scrum. My tips are based on my numerous Scrum coaching experiences, and I believe them to be consistent with the Scrum Guide.

Tip – a practice that is definitely worth consideration, but might only be good in a few or very specific contexts or team situations. More on that here.
Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.


Tip #1: Try to never schedule backlog refinement during the first or last 20% of the Sprint.

During the first 20% of the Sprint, the team is just getting started on this Sprint’s work, so you’ll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that’s not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog refinement.


Tip #2: Treat the backlog refinement meeting just like the first part of the Sprint Planning Meeting

 

  • Often called “The”What” of the sprint planning meeting, this part of the meeting talks about what will be developed in the upcoming sprint.
    • The PO presents the backlog items (often User Stories), the team ask for clarifications, and then the items are estimated by the team.
      • The PO then might indicate that priorities will change based on the estimate. Good! That’s the kind of collaboration that’s supposed to occur!

 


Tip #3: Make sure the PO knows that, during all of this sprint’s backlog refinement sessions, they will be expected to present enough work to last about 2 Sprints *beyond* the current sprint.

The reason for bringing this much work to the meeting is two fold:
1. Often times PBI’s will be de-prioritized based on feedback in the meeting, so you want enough work leftover that you’ll be ready to fill a sprint.

  • One common reason: External dependencies, or coordination with another group outside this team.

2. It’s a good practice anyway to have some of finely refined PBI’s beyond what you’re working on in a Sprint in case someone frees up and needs more work.

The PO may need to collaborate with the team to know how much work 2 Sprints worth is, but it need not be a lengthy discussion — just a very rough guess. Hopefully your team has seen the PBI’s at a Release Planning meeting or in some other backlog refinement discussion meeting. If not, then the PO can discuss the new PBI with a team member or two (informal product backlog refinement) to get a feel for the very rough effort involved (but be sure not to communicate this rough estimate to the team — don’t want to anchor/skew their initial estimates!).


Tip #4: The backlog items should be fine grained and well understood by the PO or a Dev Team member for this meeting to work well. Try to have an initial set of acceptance tests defined before the meeting occurs.

When the PO or a Dev Team member brings a backlog item to the meeting, what you don’t want to hear is, “Ok, I don’t have a lot of details on this item, but I’ve got the basic gist (or first draft) of it.” What you would rather hear is this “I’ve worked on this item and I have informally collaborated with both the customers and the team on it. I have a really good idea of the details of the backlog item as well as the acceptance tests for the PBI. It’s fairly solid, and I think there’s enough information there to start work almost immediately!”

Even if the initial acceptance tests are high level, that is better than no acceptance tests at all. The more the PO and team focus on getting to good detailed acceptance tests, the better.

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.


Tip#5: Make sure everyone understands that estimates are not final until a PBI has been accepted into a sprint.

Since the team is getting a preview of the PBI’s, don’t let the team stress out too much on the estimates. Let them know that a PBI’s estimate is not final until the PBI has been accepted into the sprint. If someone comes up with new information between the backlog refinement and the Sprint Planning Meeting, they are free to bring it up and re-estimate the PBI. This brings us to the converse of this tip.


Tip #6: Make sure everyone understands that Product Backlog order is not final until a PBI has been accepted into a sprint.

The PO is free to change the order of the backlog between the backlog refinement and Sprint Planning Meeting. This is ok. We welcome late change, remember? In practice, though, I’ve found big ordering changes happen rarely between the backlog refinement and Sprint Planning meeting, maybe 10% of the time or less.

While it may be frustrating for PBI’s to change order often, remember that this kind of information is something we want sooner rather than later.


Tip #7: Keep your eye on the goals of the meeting

One of the goals of the meeting is that, when it’s over, the team has a handful of PBI’s queued up and ready to roll into a Sprint, and also has enough for the next two sprints beyond the current one. All major questions have been answered (or at least assigned to someone to answer), and the team feels confident and knowledgeable about the upcoming work. Of course, like everything, not every last detail will be known, but it’s not for a lack of trying. At the end of the meeting you might try asking this of the team: “Of all of the PBI’s that were presented, a) which ones would make you feel very uncomfortable if you had to start tomorrow? and b) which ones do you not feel confident at all in estimating?” If any of these kinds of risk are identified, assign someone to help mitigate that risk before the upcoming sprints. This brings us to our next tip.


Tip #8: Assign action items for any big risks or unknowns

For big requirements issues, this probably means assigning the issue to the PO. For big technology risks or unknowns, this means assigning a dev team member to research the issue at hand. The person assigned should be ready to report on the action item at or before the next refinement meeting or definitely before (or at) the Sprint Planning Meeting. This will usually involve re-estimating the item based on the new information — and that’s perfectly acceptable. Who does the assigning? In general, to support self organization, the Scrum Team members should volunteer to take an action item. The Scrum Master can help by asking questions like: “Who can take this one on and get back to the team on this?”. Avoid having any one dominating person assigning action items to people — that’s not very self organizing.


Tip #9: Remember that backlog items (and/or User Stories) are a collaboration between the PO and the Dev Team

The final responsibility for making sure the PBI’s are adequately detailed for the development team’s use falls on the Product Owner. However, don’t take that to mean it’s the PO’s job to do all that work. The items should be the results of a collaboration between the PO and the dev team(and also probably between the PO and the customers or end users). It is perfectly acceptable, and in fact encouraged, that the PO meet with 1, 2, or all members of the team to help detail a PBI, prior to a refinement session (what I call “informal backlog refinement”). It is also perfectly acceptable if Dev Team members do the vast majority of refinement activities in direct consultation with users and stakeholders. Schedule meetings or have spontaneous collaborations as necessary, with the end goal being a well thought out, well detailed PBI when it is presented at a backlog refinement session. It is very atypical for a PBI to be one that is new to every single developer at a backlog refinement session. If this happens, consider it a bad smell and try to get developers involved earlier.

We highly recommend that you read the “Product Backlog Management Leader” section in our very best article on the Product Owner role: The New New Product Owner.

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.


Tip #10: Remind the Dev Team to review the PBI’s to be discussed about 24 hours prior to the refinement session.

If your PBI’s are documented in any way before a backlog refinement session (such as on a wiki or on index cards), send a reminder to the dev team to review them so they are prepared to speak intelligently about them.

If the PO is making lots of last minute edits right up until the refinement session, much of the information will be seen for the first time in the meeting, which can make the meeting last longer and be more confusing. Ideally, the PO should target their editing efforts at being ready 24 hours prior to the backlog refinement session.


Tip #11: Definitely feel free to split PBI’s during this meeting.

If anyone on the Scrum team feels the need to split items, during a refinement session is a perfect time to do it. You’ll probably want to re-estimate them too, and that’s fine. I hope it also goes without saying that if you split an 8 point PBI there should be no emphasis on making sure that the split out PBI’s all add up to 8 points. Just re-estimate them as if they were new, independent, PBI’s.


Tip #12: Optimize your time in the meeting.

For PBI’s that are well defined, just discuss and quickly estimate. For PBI’s that have already been discussed in a previous refinement session, you only really need to revisit them if there is new information about them. For PBI’s where there is new information, just discuss the new information enough to be able to give a new estimate.


Tip #13: Don’t be afraid to discuss a couple of items that are farther down the backlog

Sometimes there will be a need to discuss a backlog item that is further down the backlog. Here are some reasons for doing that:

  • The PO needs to gauge the rough size of a PBI
  • The dev team needs to identify external dependencies that will need to be started on ASAP while waiting for the rest of the item’s details to be flushed out.

There can be many other reasons, too. While we don’t want to get into a habit of doing BRUF (Big Requirements Up Front) or BDUF (Big Design UP Front), there are rare situations where looking at a backlog item that is farther down the road is advantageous to the team and the organization as a whole. Don’t be afraid to do it, but be wary of slipping back into BRUF and BDUF.


Tip #14: Strongly consider doing some informal backlog refinement before the full team backlog refinement.

  • Informal Product Backlog Refinement
    • The Product Owner will work with zero or more dev team members or stakeholders to refine stories and their order in the backlog. Said another way, this is a lighter more informal way to refine the items in much the same way the refinement is done in the Weekly Team Backlog Refinement. This kind of informal refinement should be a daily, if not hourly, occurrence for the Product Owner.
      • When the PO gets together with development team members (early collaborators), she should strongly consider making sure that the three amigos are there.
        • Also feel free to bring stakeholders in to discuss.
      • Development team members should feel free to discuss relative sizes with the PO, but I encourage teams to wait to record any estimate until the entire team has estimated the item first. Said another way, the early collaborators should try to avoid skewing or anchoring the entire Dev Team’s estimates.

 


Tip #15: Don’t be afraid to introduce late breaking PBI’s. Try to minimize them, but embrace them when they happen.

Remain Agile! Some of the major goals around doing backlog refinement are to reduce unknowns and risks, but not all risks are easily identifiable beforehand. Backlog refinement is not meant to eliminate risks, only to minimize them. Late breaking PBI’s will probably still happen (hopefully rarely), and they should generally be welcomed by the team. On the other hand, if it seems like most of your backlog items are late breaking, that is generally a bad smell.

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.


Tip #16: Meeting Attendees: The entire Scrum Team + rare appearances by other key people

The meeting attendees should generally be, at the minimum, the entire Scrum Team. On rare occasions, you will need other key people, but prefer keeping non Scrum Team members out of the meeting as a general rule. From time time to time, it will be useful to have a non Scrum Team member appear, but even those appearances should be limited. Try to limit the “other key people” to only attending while the relevant backlog items are being discussed.


Tip #17: Experiment with the amount of refinement that your team does.

In the beginning, until you get “two sprints ahead” (beyond the current sprint), you will need more refinement than normal. After you get caught up, experiment with how much refinement is usually needed to stay “two sprints ahead.” When I coach teams, I usually tell them that 1-2 hours per week is typical, and that until they are “two sprints ahead,” they should double that amount. Don’t use these numbers as hard and fast rules, but instead as a starting place to adjust the time up or down as needed. The Scrum time-box for refinement is 10% of the Dev Team’s time per sprint. For a 2 week sprint, that means 1 full day (8 hours) per sprint. I find that most teams can stay well under that time box once they’re “two sprints ahead.”


Tip #18: Be sure to retrospect, inspect, and adapt!

Just like every other Scrum practice, it is absolutely imperative that your team inspects and adapts their practices. If your team feels like backlog refinement is a waste of time, then there are almost assuredly impediments that need removing. Do a “Five Why’s” analysis and read up on good backlog refinement techniques.


Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.

Conclusion

If backlog refinement is done well, you can skip the entire “What” part of the Sprint Planning meeting and go straight to decomposing PBI’s in the “How?” part of the meeting. How’s that for a short planning meeting? Most teams will find that having regular product backlog refinement increases overall team knowledge and eventually increases productivity, usually by a large factor.

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.

Related articles on ScrumCrazy

Learn more about great Product Backlog Refinement practices in our Agile Requirements and Product Owner Techniques classes.