Eliani RamosVice President| PMI-SCJoinville, Sc, Brazil
We have 6 Agile Scrum Teams. These teams practice Scrum cerimonies. We have a PMO who is responsable to manage the strategic projects that involv all these teams. During the planning processes, we planning risks using best practices from PMBok. How do you are monitoring the risks during the sprints? On the daily meeting? Or do you have some specific meeting about risks? What are the best practices do you recommend me? Saving Changes...
Are you just asking about the process once the sprints begin (project risk), or are you also asking about risk management during the product lifecycle (product risk).
I realize that product and project risk are not the most accurate labels. It's all really product risk. I'm curious what you're doing to manage risk before the sprints begin and who owns the risk management process in your organization.
...
1 reply by Eliani Ramos
Apr 28, 2017 1:51 PM
Eliani Ramos
...
Thank you Aaron. I'm talking about both one.
We have a PMO who is responsable to the portfolio management and we evaluate the risks thinking of the product evolution, ways we have to implementation with the Business owner.
But at this stage, we only have the scope at a macro level.
Our product owners detail the scope at a level of user stories and discuss this USs with the agile teams.
We have a high indice of sprint fail.
I'm very concerned about the causes of the fails. They have a lot of discoveries during the sprints. But not simple discoveries. Discoveries that impact other teams too.
What can I do to minimize this situation?
Saving Changes...
Denise CantyAgile Coach, Life Coach, Author, Senior Project-Program Manager| Cenden CompanyWashington, Dc, United States
Risk Management in Agile Software Development is managed by working on the highest priority and high-risk user stories early. The backlog (risk adjusted) should include these risky AND high priority items in early iterations, The Product Owner (and stakeholders) decide upon priority levels and the agile team (everyone) can provide feedback into risk levels for each user story.
...
1 reply by Eliani Ramos
Apr 28, 2017 1:35 PM
Eliani Ramos
...
thank you Denise.
During the sprint planning the teams must deal with the risks of each User Story?
Saving Changes...
Eliani RamosVice President| PMI-SCJoinville, Sc, Brazil
Apr 28, 2017 1:23 PM
Replying to Denise Canty
...
Risk Management in Agile Software Development is managed by working on the highest priority and high-risk user stories early. The backlog (risk adjusted) should include these risky AND high priority items in early iterations, The Product Owner (and stakeholders) decide upon priority levels and the agile team (everyone) can provide feedback into risk levels for each user story.
thank you Denise.
During the sprint planning the teams must deal with the risks of each User Story?
...
1 reply by Denise Canty
Apr 29, 2017 6:47 PM
Denise Canty
...
Yes, risks are addressed during planning the user stories that will be included in the risk-adjusted backlog.
Saving Changes...
Eliani RamosVice President| PMI-SCJoinville, Sc, Brazil
Apr 28, 2017 12:11 PM
Replying to Aaron Porter
...
Are you just asking about the process once the sprints begin (project risk), or are you also asking about risk management during the product lifecycle (product risk).
I realize that product and project risk are not the most accurate labels. It's all really product risk. I'm curious what you're doing to manage risk before the sprints begin and who owns the risk management process in your organization.
Thank you Aaron. I'm talking about both one.
We have a PMO who is responsable to the portfolio management and we evaluate the risks thinking of the product evolution, ways we have to implementation with the Business owner.
But at this stage, we only have the scope at a macro level.
Our product owners detail the scope at a level of user stories and discuss this USs with the agile teams.
We have a high indice of sprint fail.
I'm very concerned about the causes of the fails. They have a lot of discoveries during the sprints. But not simple discoveries. Discoveries that impact other teams too.
What can I do to minimize this situation?
...
1 reply by Aaron Porter
Apr 28, 2017 6:42 PM
Aaron Porter
...
While you won't have detailed user stories before planning, your product owner should be working with stakeholders to define desired features, prioritize them, and develop a roadmap, before sprint planning. If the product owner is working with stakeholders to identify product risks, it should help to identify areas that also affect other projects more than working with the project team would. The stakeholders are more likely to have insight into and interests in other projects.
When you say that your sprints fail, do you mean that the teams regularly do not finish planned work? The quick answer is to reduce your velocity, but that won't actually solve any problems. My first guess is that the team is not asking enough questions of the product owner, resulting in insufficient information to size the stories properly and the inability to finish the work during the sprint.
Are you familiar with the concept of a "definition of ready?" It's the minimum detail that needs to be included on a story card before it can be sized and added to a sprint - more than just the story. You need to be careful that you don't turn agile into waterfall by including requirements that can be worked out during the sprint. The purpose of the definition of ready is to drive the conversation and make sure you get enough information to accurately size your work.
Keep in mind that the point where you are getting enough detail may not be clear. If your velocity has not been consistent, there's a good chance the team will have to relearn its velocity. Unless it's way off, wait to adjust your velocity until after the amount of surprises you are finding during sprints is significantly reduced. After a couple of sprints without surprises, the team should get a better idea of what their velocity should be.
I don't know what you know - I apologize if I've assumed incorrectly and told you things you already know and do. Has any of this been helpful?
Thank you Aaron. I'm talking about both one.
We have a PMO who is responsable to the portfolio management and we evaluate the risks thinking of the product evolution, ways we have to implementation with the Business owner.
But at this stage, we only have the scope at a macro level.
Our product owners detail the scope at a level of user stories and discuss this USs with the agile teams.
We have a high indice of sprint fail.
I'm very concerned about the causes of the fails. They have a lot of discoveries during the sprints. But not simple discoveries. Discoveries that impact other teams too.
What can I do to minimize this situation?
While you won't have detailed user stories before planning, your product owner should be working with stakeholders to define desired features, prioritize them, and develop a roadmap, before sprint planning. If the product owner is working with stakeholders to identify product risks, it should help to identify areas that also affect other projects more than working with the project team would. The stakeholders are more likely to have insight into and interests in other projects.
When you say that your sprints fail, do you mean that the teams regularly do not finish planned work? The quick answer is to reduce your velocity, but that won't actually solve any problems. My first guess is that the team is not asking enough questions of the product owner, resulting in insufficient information to size the stories properly and the inability to finish the work during the sprint.
Are you familiar with the concept of a "definition of ready?" It's the minimum detail that needs to be included on a story card before it can be sized and added to a sprint - more than just the story. You need to be careful that you don't turn agile into waterfall by including requirements that can be worked out during the sprint. The purpose of the definition of ready is to drive the conversation and make sure you get enough information to accurately size your work.
Keep in mind that the point where you are getting enough detail may not be clear. If your velocity has not been consistent, there's a good chance the team will have to relearn its velocity. Unless it's way off, wait to adjust your velocity until after the amount of surprises you are finding during sprints is significantly reduced. After a couple of sprints without surprises, the team should get a better idea of what their velocity should be.
I don't know what you know - I apologize if I've assumed incorrectly and told you things you already know and do. Has any of this been helpful? Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Great advice given above, and even if Aaron has not assumed correctly, sound advice nonetheless. Seemingly there is risk assessment up front at a high level once the product is known, with further assessments and responses as user stories are formulated and the work is completed. Exposure, as noted, can be done through the scrum meetings.
What is specifically meant by sprint failure(s)? Unfinished planned work? Not meeting expectations? Saving Changes...
Community Champion
