Get Ready to Sprint with Rational Team Concert
Keep your agile team on track and productive by focusing on stories they can finish
If the top item on your personal backlog is "Go on vacation," would you get in the car and start driving with only that much information? Of course not. You'd want to know at least how many days you had and where you were going, so you'd know how much and what kind of clothes to pack (and whether you should be driving to the airport). Depending on how adventurous you are, that might be enough for you. But for a lot of people, that would just be the beginning of the data gathering and arrangement making before they even set foot out the door.
If yours is like many agile teams that use scrum project management methods, your product backlog is full of items that represent value for your customers and clients. It probably includes stuff like "As a frequent flier, I want to be able to easily transfer mileage credit to a friend or family member."
The problem for many teams is that is all of that information is in the Product Backlog, in plausible statements that could add up to an interesting product or enhancement. Backlog items like that frequent flier user story are not actionable. A team cannot pluck that off of the backlog list and get to work. There's not enough information for detailed work breakdown and estimation at the sprint planning meeting. More importantly, there's not enough information to make sure that the feature turns out as planned and can be successfully delivered. As teams move to a continuous delivery mode, it becomes crucial to have actionable and deliverable work at the top of the backlog list.
And nothing will choke the productivity out of a team (agile or any other kind) like not having work that can be done. Sure, they could simply charge forward (and might have to), following their best guess about what needs doing and how. But the sprint planning meeting might take up the whole first day of the sprint (maybe more) if most of the stories are weakly specified. Much time will be wasted, and it's possible that the wrong work will get done anyway, but the team won't find out until the sprint review meeting at the end of the iteration. Agile and lean teams hate rework and despise waste. A poorly prepared product backlog offers plenty of both.
The idea of backlog grooming has been around almost as long as backlogs. After a user story brainstorming session, the backlog is likely full of story summaries like the one mentioned previously, perhaps even prioritized ones that identify what the product owner considers most important for the early iterations. What it won't have is much that the team can immediately start working on. According to Mike Cohn, backlog grooming might be creeping toward becoming a Generally Accepted Scrum Practice. (See the Related topics link to his blog post "GASPing about the Product Backlog" and the lively discussion that ensued).
One reason that backlog grooming is important, even if you think your backlog is in good shape, is that you're being agile. You're responding to (and embracing) change. As deliverables come out of sprints and customers see how things are progressing, plans and priorities will change. Backlog grooming involves considering stakeholder feedback, understanding how it affects the project, and shuffling the backlog (and perhaps adding or removing items) to represent what matters most now. Mike Cohn and Roman Pinchler summarize the key attributes of a good product backlog with the acronym DEEP: Detailed (appropriately), Estimated, Emergent, and Prioritized.
Backlog grooming is simply reviewing the backlog to make sure that the ranking of items reflects current priorities and that the items at the top are detailed enough to work on immediately. A natural result of tending the product backlog with this focus is that higher-ranked stories — the ones that you'll be working on soon — require attention to make sure that they are actionable by the team. By no means does the entire backlog need to be in that state, but at least the next couple of sprint's worth should be. You need the stories at the top of the backlog to be Ready to Sprint.
What does it mean for a story to be Ready to Sprint? That's largely going to depend on the scope of the story, your team, and perhaps your product and industry. A simple story, such as a small enhancement to an existing feature that can be done by one team member, might need only a short description that identifies the preconditions and basic outcomes, and maybe a quick UI mockup for the changes. A more complex story that will require several people working together across product components will require much more. If your team has particular regulatory requirements to meet or special security issues to address, you will need to spell them out in your story description or acceptance criteria. If you don't, you can't be sure that they will get done.
Some useful Ready to Sprint criteria might be that a user story:
- Needs to be sized (in story points or whatever metric you use) and assigned a priority and rank
- Is small enough to be finished (however your team defines "done") within a sprint
- Contains sufficient detail to be planned and implemented
- Has acceptance criteria that are approved by your product owner and stakeholders and that represent the behavior of the work, if properly completed
What's important is that your team has determined what the Ready to Sprint criteria are and that they agree that only stories that are Ready to Sprint get picked for sprint planning. That agreement creates an essential forcing function for the product owner and the team: keep your backlog in good shape or no work gets done.
A well-groomed backlog allows sprint planning meetings to proceed far more efficiently. With a clear understanding of what needs to be completed for the story to meet the team's Done criteria, the team can more easily figure out who will do the work and estimate how long it should take. Then they can commit to the story with actual confidence (not just bravado). If you don't have stories that are Ready to Sprint, it won't take long until your #1 item at every retrospective is "We just didn't really understand…"
Customizing RTC to keep your team Ready to Sprint
While agile development isn't about tools and processes, nothing says you can't use great tools and processes that help your team be more effective and efficient. Rational Team Concert can be easily customized to augment how your team works. I'll present one example of how you can customize Rational Team Concert to implement a Ready to Sprint attribute and use it in plans, queries, and dashboards to help make sure your team is always Ready to Sprint. For the purpose of example, I'll go farther than you might want to, so feel free to leave out steps that may not provide value for your team.
Here are the basic tasks:
- Customize the Story work item type by adding the Ready to Sprint attribute.
- Customize the Story Editor presentations to display the new attribute.
- Update permissions so only Product Owner and Scrum Master roles can update Ready to Sprint.
- Create and install the Ready to Sprint validator.
- Update team operational behavior to enforce the validator's restriction.
- Create a Backlog Grooming view of the Product Backlog that can be used during backlog grooming meetings to highlight stories that need.
- Create a query to identify stories that need attention and install it into a dashboard widget.
You'll mostly use the Rational Team Concert web client, but you will need to use the Eclipse client for a few steps that are not yet available in the web client. All screen captures and described behavior is based on Rational Team Concert 4.0, and instructions assume a general familiarity with the software. You will also need administrative permissions (at least Project Area administration) for some actions.
Customize the Story work item
- Using the web UI, navigate to the administration page for your project area then to the Work Items section. Select Type and Attributes (see Figure 1).
- In the drop-down menu at the top of the section, change the Work Item Type to Story.
- In the Attributes section, select Add.
- In the pop-up window, add a Boolean attribute named
Ready to Sprint.
Figure 1. Adding the Ready to Sprint attribute to the Story work item type
Customize Story Editor presentations
Each work item type has multiple editor presentations. You'll add it to only the main editor presentation for this example, but you can add it to all appropriate presentations if you prefer.
- From the same Work Items section, choose the Editor Presentations subsection, and change to the com.ibm.team.apt.editor.story work item type.
- Use the plus sign in the Details section to add a new presentation, and choose your new Ready to Sprint attribute. Set its kind to Boolean, and click OK.
Figure 2. Adding Ready to Sprint to the Story Editor presentation
- This will place the new item at the end of the Details section, but it's more important than that, so drag it up and drop it after the Story Points attribute.
- Save your changes.
Figure 3. Drag Ready To Sprint to more prominent location
- (Optional) You could make Ready to Sprint hidden on Story creation. There's literally no chance that it will already be Ready to Sprint because the story is being entered for the first time.
- Hover your cursor over the Ready to Sprint attribute and click the pencil icon to edit the presentation's attributes.
- Next to the Properties section at the bottom of the dialog, click Add, select the hideIfCreation key, and set its value to True.
- Save the changes that you've made so far.
Figure 4. Hide the Ready to Sprint attribute for Story creation
Update permissions for Ready to Sprint
Consider this question: Should anyone with work item edit rights be able to declare the story ready, or should only the product owner or scrum master be entrusted with that determination? To restrict changing this value to the product owner and scrum master, you need to remove the permission from the other roles because, by default, everyone can update the value.
- While still in the administration area, choose Permissions and then Team Configuration to get a list of Roles and Permitted Actions.
- Choose the Everyone role, and scroll down the Permitted Actions list to open each of these groups:
- Work Items
- Save Work Item
- Modify the work item
- Find the Modify the Ready to Sprint' attribute, and uncheck it.
Figure 5. Remove update permissions for Ready to Sprint from the Everyone role
- Repeat this process for the Team Member and Stakeholder roles, and then Save your changes.
Now, when people other than the product owner or scrum master tries to update the Ready to Sprint attribute, they will get an error message similar to the one in Figure 6.
Figure 6. Notification when attempting to update Ready to Sprint without permission
Create and configure the Ready to Sprint validator
Rational Team Concert has a rich capability for customizing attribute behavior, both with built-in customization features (such as regular expressions) and custom ones through script-based programmatic features that you can add. There is a good article in the Jazz.net library on the topic in general. See the link to "Customization of Work Items in Rational Team Concert" in Related topics. In this section, you will add a script-based validator that will test that various attributes meet the Ready to Sprint criteria and that they can be used to block changing the value to True when they do not. This is especially useful if you chose not to restrict permission to change this value to just Product Owners and Scrum Masters.
The script used for this example (RTSValidator.js) will check that the story Description and Acceptance Test descriptions are not empty and that the story has a reasonable complexity value and priority assigned. You can modify the script to suit your team's definition (I've gone a bit overboard in this example intentionally). The script is included with this article in the Downloads section (you can download it before proceeding). This article isn't about scripting, so I won't discuss specifics of the script operation.
For this example, you'll add a validator attribute customization (using the Eclipse client, because this customization is not yet available in the web client).
- Start by opening the Project Area in the Eclipse client.
- Select the Process Configuration tab.
- Under the Project Configuration category, navigate to the Work Items Attribute Customization section, and select Validators and "then Add.
- Name the script
Ready to Sprint Validator.
- Set the Provider to be Script Based Validation.
Figure 7. Adding the Ready to Sprint validator
- After adding the validator, it needs to be configured to use the script that you wrote (or downloaded). Use the Browse feature to locate the script wherever you placed it on your system.
Figure 8. Configuring the Ready to Sprint validator
Notice the Reload button. Whenever you change the script (and assuming that it is in the same location), you'll need to reload it to upload the latest version to the Rational Team Concert server.
If you see a warning displayed on the Configuration panel about process attachment scripts not being enabled on your server, you (or someone with Jazz Admin privileges) will need to edit the Advanced Properties for the Change and Configuration Management's Application Administration page and set the Enable Process Attachment Scripts value to True.
Figure 9, Enable scripting for attribute customizations
- For the validator to be configured for your Ready to Sprint attribute, you must return to the Work Item > Types and Attributes configuration section of the project configuration and edit the Ready to Sprint attribute on the Story work item type to use the validator that you just created.
- Then save your changes.
Figure 10. Configuring the validator to the Ready to Sprint attribute
Now when you open any Story in the Work Item Editor, the Ready to Sprint validator will run. If Ready to Sprint happens to be checked and any of the programmed Ready to Sprint conditions are not met, the field will be decorated with an error icon, and hovering your cursor over the icon will display a message indicating what is wrong. (The image in Figure 11 is composed for clarity. The normal display covers the Ready to Sprint attribute area when hovering over the error decoration.)
Figure 11. Sample validator decoration and message
Update team operational behavior to enforce the validator restrictions
The message from the validator, even though showing as an error, will not block saving the item unless the team Operation Behavior that requires attribute validation as a precondition is turned on (which it is not by default in a scrum project area). If you want to keep this value from being set to True unless the programmed conditions are met:
- Go back to your Eclipse client and select the Operation Behavior section under Team Configuration.
- In the table of operations, scroll to the Save Work Item (server) row and select the Everyone column.
- In the Preconditions section, add the Attribute Validation condition.
Now, if there are any attribute validation errors, including Ready to Sprint, they will block saving of the item.
Figure 12. Adding the Attribute Validation precondition
That wraps up the work items aspect of the changes.
- Important: Add at least five stories, and provide values for some of your key attributes, and plan them for the backlog. You'll need these extra stories to make the plan customizations that you're about to make more interesting.
Create a Backlog Grooming view of the Product Backlog
Next, you'll make a better plan view for backlog grooming, and then add a dashboard widget to help draw attention to stories that are not yet Ready to Sprint.
But first, a little "accounting" work. Although you've added Ready to Sprint as a work item attribute for a Story, the planning side of Rational Team Concert doesn't know much about that attribute. If you want to use it in plan views, even as just a display column, you need to tell the Planning component about the new attribute.
- In the Eclipse client, go to the Plan Attributes section of the Planning configuration data.
- In the Attribute Mapping section, add Ready to Sprint (and while you're at it, add Acceptance Test, too).
- Save your changes.
Figure 13. Add Ready to Sprint as a planning attribute
Now Ready to Sprint and Acceptance Test will be visible when you are configuring plans.
- In the Rational Team Concert web interface, navigate to the Product Backlog plan.
- In the drop-down menu next to the View As: box, choose Create View.
Figure 14. Creating a new view for the Product Backlog
- In the dialog window, enter the name for the view as
Backlog Grooming, and make sure that the Options tab is selected.
- Use the More menu to add three Colors options, and configure them as Figure 15 shows.
- If you are not familiar with editing plan view colors, click the text of the colored box to change it, and use the drop down arrows to change the colors.
- Type the attribute and condition in the text box. Be sure to include the empty quotation marks with a space between them at the end of the Acceptance and Description items.
Figure 15. Color options for the Backlog Grooming view
You can see from the lines of the plan displayed below the configuration dialog how the items in the plan will be tagged with different color flags, indicating what still needs attention. Ones marked with only "!RTS" might need a final review before setting them as Ready to Sprint.
- Approve the changes to the view and save the changes to the plan.
You could make a similar view called Sprint Planning that used a Filter option to exclude stories that are not marked Ready to Sprint from consideration.
Create a query and install the Stories That Need Attention dashboard widget
Rational Team Concert dashboards are a great way to pull together information that matters and make it very easy to find. Any group of constituents in the project can have a dashboard (or at least a tab on a dashboard) that highlights what matters most to them. You'll use a simple Work Items Query widget with a custom query that highlights stories that need attention to get them Ready to Sprint.
- Start by creating a custom query that finds unresolved stories planned for the backlog and are either Medium or High priority and not marked Ready to Sprint.
- Name the query
Stories that need attentionand save it.
You can easily adjust the query to suit your teams' needs.
Figure 16. Definition for the "Stories that need attention" query
- Adjust the columns and sort order to suit your needs.
Figure 17 shows how the example is configured.
Figure 17. Column display configuration for query
- If you made additional changes, save the query.
Use the Details tab of the query editor if you need to adjust sharing options for the query. You will need to share it with at least your team (and possibly in the project area) for it to work in the dashboard for other team members.
- Go to your team or project dashboard.
- From the Work Items category, add the Work Items widget (or just type
Work Itemsinto the filter box to find it without browsing).
Figure 18. Adding the Work Items widget to the dashboard
- Configure the widget by selecting the custom query that you just made (and perhaps limit the number of items returned by the query so the widget doesn't take over the page).
Figure 19. Configure the dashboard widget
Now your team or project dashboard will show, at a glance, the top stories that need elaboration. When you hover your cursor over one of them, the pop-up window will show a summary of the attributes, and you can quickly see which parts still need work.
Figure 20. Stories That Need Attention widget in use
Agile teams prefer to focus and finish, working on one well-defined item until it is done. Asking them to work on stories that are not Ready to Sprint diminishes their ability to perform at their highest level, thus slowing the delivery of value to customers. These simple customizations should help keep your team Ready to Sprint, performing at its best.
Many thanks to my teammates Aaron Burns and William Vorhees and my manager Kai-Uwe Maetzel for their technical reviews and insights for this article. Thanks also to the editorial staff who make everything better and developerWorks such a valuable resource.
- Read these for additional helpful information related to this article:
- Customization of Work Items in Rational Team Concert by Jan Wloka and David Karam of IBM (Jazz.net, September 2012).
- Advanced customization of Rational Team Concert project areas, a two-part article by Seema Gupta of IBM (IBM developerWorks, August-September 2012).
- Progressive refinement of user stories in the product backlog by Mike Cohn of Mountain Goat Software (IBM developerWorks, January 2013). GASPing about the Product Backlog and Make the Product Backlog DEEP by Mike Cohn (Succeeding with agile blog, March 2012 and December 2009, respectively), as well as the chapter on writing user stores from User Stories Applied: For Agile Software Development (Addison-Wesley Professional, 2004).
- INVEST in Good Stories and SMART Tasks by Bill Wake (XP123.com, August 2003).
- Find out more about Rational Team Concert:
- Find Rational Team Concert articles and links to many other resources on IBM developerWorks, and check the product overview page, features and benefits, system requirements, and the user information center.
- Check the Rational Team Concert page on Jazz.net.
- Watch the Using Rational Team Concert in a globally distributed team webcast or a demonstration of the Dashboards and reports, or listen to the podcast about IBM Rational Team Concert and Jazz.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the Getting Started ones are free.
- Download Rational Team Concert from Jazz.net and try it free on up to 10 projects for as long as you want (requires registration). If you'd prefer, you can try it in the sandbox instead, without installing it on your own system.
- Evaluate IBM software in the way that suits you best.