Q: How are defects reflected in a burndown chart? Any recommendations around how to better handle defects throughout the sprint?
A: A best practice is to treat your defects as two different classes:
- Defects found while developing a user story should be attached to that user story, and not estimated with points. The associated story cannot be accepted until the defect is resolved. This means that a team can lose credit if this isn't done before iteration end. This is a good learning opportunity.
- Regression defects found by users and support should be estimated in points, just like user stories, and prioritized on the backlog. In future planning sessions, the team can balance the value of fixing a past error or providing a new feature. Those types of defects affect a burndown, because they have an independent size.
Q: What is an iteration in relation to a user story?
A: A user story is a small feature or deliverable piece of work. An iteration is a set time frame, where a team commits to finishing one or more user stories.
Q: How do I track epics in CA Agile Central? Is it a type of user story? How should they be estimated? How do we take them on iterations and close?
A: An epic is defined as a story too large to be completed in a single iteration. Since that's the case, they cannot be scheduled in an iteration. Instead, break the large project down into smaller chunks that can be scheduled in iterations. From the parent story, you can see the status of the children as they are completed. Learn more here.
Q: If stories are not completed within the sprint, do the points stay within the current sprint? And how do you keep track of the points when spanning over multiple sprints?
A: Here’s a great article that answers this question.
Q: Other than recording time left to do on tasks, what is the best way for tracking time for a team to show utilization?
A: Consider using CA Agile Central Time Tracker.
Q: Should defects be traced to user stories or user story tasks?
A: Defects can only be associated to user story objects in CA Agile Central.
Q: As a product matures, how important is the visioning? Assuming the roadmap is not completed.
A: Visioning is extremely important! The more your product matures the more important it becomes to identify those areas where you are going to maximize what you do well and differentiate yourself in the existing market. Visioning and road mapping is something that can change as the market changes, but having that long-term goal will make it easier to prioritize work at the delivery team level. Leveraging CA Agile Central Portfolio Manager (RPM) can help connect strategy and execution so that you know you're on track to make those long-term goals.
Q: Can estimation calculation go wrong because of other team dependency work? Is there a way we can track the overall waiting time?
A: We recommend using the Cumulative Flow chart for this in tandem with the predecessor-successor functionality in CA Agile Central. Identify those inter-dependencies and then for the stories you would be able to see how long work is staying in a specific state. It’s a good indicator of issues. In addition, you can leverage epics within CA Agile Central to gain visibility into large chunks of work spanning multiple iterations (and different projects). Using epics with the various epic apps in the catalog or on the Reports tab will give you visibility into issues you may be having.
Q: How do you plan for spikes if the research story will take the entire sprint?
A: If this research work is critical to moving forward, it's fine to have a spike story span the entire length of an iteration. Alternatively, you could break that spike down into several smaller chunks, each having a goal of identifying needs in a different area of the proposed work.
Q: Who updates the task board?
A: Individual team members should be responsible for updating the status of their tasks. However, only the product owner can update a user story from completed to accepted.
Q: We had an iteration disappear from a sub-project, so we had to re-create it. Is there anyway to figure out why this happened?
A: It's likely that another user with editor permissions to the project deleted the iteration. Unfortunately, this action cannot be traced directly. You may open a support case for additional suggestions to locate the source of the deletion.
Q: How does one capture a defect in CA Agile Central?
A: CA Agile Central supports defects, which can be estimated with points just like user stories. You can associate a defect to a user story when it is discovered during an iteration, or create a stand-alone defect when a regression (fix to be scheduled later) is discovered. Learn more here.
Q: The story point does not really get estimation better than just using hours and people. You cannot really compare two stories with the same points at the same time and you cannot compare two stories with same points at different times.
A: Remember, story point estimation is all about relative value, not exact number of hours to complete. You estimate twice at two levels: relatively at the story and team level, and then more precisely (but it’s not always exact!) at the task and hour level. This is the difference between sizing and estimating. You want to be wrong at times: these serve as cues to learn about why estimate doesn't line up with what happened. Read more here.
Q: Can test cases and test sets be traced back to tasks or is it just traced back to user stories?
A: Test cases can be an independent object when using CA Agile Central Quality Manager or Unlimited Edition subscriptions. Otherwise, they can only exist as objects associated to a user story. Tasks can be associated to test cases, but not the other way around.
Q: In your examples, test plans are tasks. Any issues with them being child user stories instead?
A: That can work, but you may lose the value of rolling up task status into overall user story status. Since parent stories cannot be scheduled into an iteration, you can't have the same reporting at this level.
Q: Let's say you have a task that you estimate to be 10 hours. On the first day, everything looks good and you think there are only 2 hours left then the next day you hit a technical issue, and now estimate 20 hours to complete it. Does the burndown bounce up?
A: The burndown chart could be affected on the day you change the To Do field from 2 hours to 20, if the chart is left to lock overnight (daily data on CA Agile Central charts locks into place at midnight workspace time). This serves as a reminder to discuss the task in the iteration retrospective. Ask questions like "Why did these issues arise?" and "What action items can we assign to prevent similar issues in the next iteration?".
Q: So you don't have each team come up with their own point scale? Who is responsible for coming up with the commonly known stories?
A: The teams as a group decided to use a common scale. You can have each team use an independent scale, but we recommend using the same numbering system so point values are constant.
Q: Is it recommended to remove user stories from the current iteration?
A: There are some separate philosophies on this in the scrum community. One side believes that if you commit to a story and miss that story, it becomes unfinished, unaccepted, and dormant in the iteration. You then copy that user story into the next or a future iteration. Another philosophy believes in partial credit: move a user story over when you have done some work on it. You can do this in CA Agile Central using the story split functionality, to move over user stories and the unfinished tasks and getting credit for that work that has been done in the current iteration. You can do both in CA Agile Central, just make sure to go over what occurred during a retrospective!
Q: User stories are estimated in terms of story points. Can sprints have sprint points concept as well? If so, how are sprint points and actual estimates correlated?
A: Over time, you know that your team completes about 20 points of user stories per iteration. This value is known as your velocity. In the next iteration, you know you can plan for 4 stories at 4 points each (leaving capacity for unknown issues) or 2 stories at 8 points each, and so on. Your iterations have a value (the Resources field in CA Agile Central) that correlate with a value on stories (the Plan Est field).
Q: What about timesheets specific to the project? Will it tell us overall time spent to the story? Is there any chart for this?
A: To track estimated time versus actual time you can leverage both CA Agile Central's Time Tracker module and also make the Actuals field visible in CA Agile Central. In CA Agile Central, the Actuals field is hidden by default because teams can sometimes use this as an excuse for bad estimates. You can unhide Actuals by contacting your subscription administrator to make the change for your workspace.
Q: Can there be multiple product owners?
A: When possible, have one product owner per team and functional area of a product. Here at CA Agile Central, we have several product owners, each empowered and responsible for a different area of the application. The group plans together, so that their pieces of work push the application towards a larger goal.
Q: On the CA Agile Central Estimation Board are there point values associated with each column?
A: Yes, and you can set the column names, and the corresponding point values.
Q: Do any of CA Agile Central's graphs support the burnup concept?
Q: Is there are change log available in CA Agile Central? We had a nice burndown going this sprint but then items disappeared and when we added them back, the burndown doesn't look good anymore.
A: Yes, each iteration has a revision history where you can see who removed items and when from the iteration. Learn more here.
Q: Does CA Agile Central support user story and feature testing?
A: Yes, CA Agile Central provides many testing tools with Enterprise Edition and the CA Agile Central Quality Manager module.
Q: Should QA include test cases design when estimating user stories?
A: Yes, the design of test cases should start in parallel with the development work. The best way to enable this is to write the story such that it is a value statement. For example, "As an online user, I want to pay by credit card, so that I may purchase items without a check." With this known, testers can start building tests against an online credit card payment system.
Q: Do you recommend setting a baseline user story with a point value so that velocities can be compared across teams?
A: Yes! At CA Agile Central, we have big easel sheets with a group of commonly known stories posted for each team. The teams use those stories as their baseline. Conversations sound like this: "Well, this proposed feature seems to be about as much effort as our sample 'Create login button' story was, and we call that 5 points. So let's estimate this new work as 5 points."
Q: Does an estimate include testing time?
A: Yes! Estimates are a value of the team's effort, including testing activity, not individuals or departments.
Q: Should demos be held in the last day of the sprint?
A: You definitely want to demo prior to going into review and planning for the next sprint so you can take that feedback and use it for reprioritization of the backlog. Here at CA Agile Central, demos are done at the end and feedback time allows for re-focus.
Q: Straight line using a full month convention might be one user story, correct?
A: Yes, possibly. However, if a piece of work cannot be delivered start-to-finish in a single iteration, it needs to be broken down to effectively track the smaller pieces.
Q: So the design needs to be completed before we start an iteration?
A: Yes, the team should have enough detail to:
- Be able to confidently commit to schedule the work in the iteration.
- Begin work immediately.
Q: If story size should reflect testing time, should stories generally have QA tasks to reflect time spent verifying that the acceptance criteria have been met?
A: Yes, the team will estimate the size of the story together, and then QA tasks can be associated to track that piece of the work.
Q: Does an epic have a format like a user story does?
A: Yes, you want to use the same format for writing an epic user story as a child user story. In fact, you'll often find that you write a story, and during estimation, discover it is too large to finish it in an iteration (making it an epic to be broken down). You can keep the description the same in that instance. Learn more here.
Q: To avoid requirements changes during the iterations should there be any sign-off mechanism from the product owner before the delivery team starts working on the iteration items (user stories)?
A: Yes. If the product owner is present during refinement and then iteration planning meetings, he or she can speak up if there are incorrect or missing requirements in the story description prior to it being planned.