How many times have you already heard form your PO about a feature: oh, that is cool, but it's not the way I thought it.
If you hear this statement frequently you should be keen on some improvements to your processes, but if you hear it once in a sprint (by the review) you are definitely in big trouble.
In this case the following questions should come up during the retrospective:
- Do our stories have clearly defined DoD?
If the stories don't have DoD or those are not well defined it is likely to fail the real target of the story. If you have questions on some of the DoD you must request the PO for negotiation. Don't be afraid of discussing on remove or add some criteria to the list, since the DoD should be negotiable anyway. Keep in mind, that detailed discussion during the sprint planing meeting might cover up some details and even led to split up stories (see some patterns on splitting stories).
- Why did our PO not complain about it during the sprint?
It's important to negotiate the stories with your PO. If you/the team has questions about the story or feels uncertain about some DoD the PO must be available for you to clarify the problematic issues. If you have the feeling that the PO is not available for the team, or the team must often wait for a meeting with the PO, it is clearly a big impediment, and your scrum master must take care about it.
After all it is likely to have recent questions about the stories, and the product owner must available for the team.
A good, committed team will depend more on the PO than on the scrum master, whereas new teams are likely need more the scrum master and less the PO.
Showing posts with label Product owner. Show all posts
Showing posts with label Product owner. Show all posts
Sunday, July 24, 2011
Thursday, July 21, 2011
We can't finish our stories! Help
You have a great team, that works hard and uses the best IDE of the market and the chaps do talk to each other; and still you they can not manage to finish the stories they have in the sprint backlog.
Seems to be a well known problem? If so, just try to answer the following questions:
- Do you have a detailed sprint planning?
You should have! And for a 4 week sprint, it should be at least 4 hours. Just an hour is not enough for that.
- Does your product owner prepares user stories for the team, with some estimation beforehand?
If she does, please take care that the team not sees the estimations of the PO. They would just influence the own estimation and might lead to untruthful commitments.
- Is the product owner really available for the team, through the whole sprint?
Take care about it. The team might have questions during the development. If they need to interrupt frequently while the product owner is not available, the story will possibly fail the sprint. Or even worth, if they develop something that is not accepted by the product owner (afterwards notabene).
- What is the average size of the user stories that are selected for the sprint?
If you feel that stories are two expansive, than consider splitting them. There are some good techniques that might help you. By splitting of stories, consider fulfilling the INVEST criterions. Another good article on this topic can be found here.
- Do you have an exhaustive DoD for your stories?
If the answer is no, than you have an insufficient sprint planning! It is of immense importance to have a well defined exhaustive DoD for each story. It helps to negotiate it with the PO. Even more important is the discussion about the DoD. Many questions and potential problems can be covered up by discussing the list.
- Is your team really committed? What is the commitment of the sprint?
It is helpful to have an overall goal for each sprint. A commitment such as: "We are going to finish all the stories selected for the sprint" is pretty much senseless. You should have something like: "With this sprint the user should be able to create and manage his profile" or it can be some nonfunctional requirement that has some impact on the user experience: "With this sprint we are going to improve the responsiveness of the GUI application." Print it onto the Story board to keep it in mind all the way long. Time to time, it can be helpful to ask the team, how they feel about the commitment.
Seems to be a well known problem? If so, just try to answer the following questions:
- Do you have a detailed sprint planning?
You should have! And for a 4 week sprint, it should be at least 4 hours. Just an hour is not enough for that.
- Does your product owner prepares user stories for the team, with some estimation beforehand?
If she does, please take care that the team not sees the estimations of the PO. They would just influence the own estimation and might lead to untruthful commitments.
- Is the product owner really available for the team, through the whole sprint?
Take care about it. The team might have questions during the development. If they need to interrupt frequently while the product owner is not available, the story will possibly fail the sprint. Or even worth, if they develop something that is not accepted by the product owner (afterwards notabene).
- What is the average size of the user stories that are selected for the sprint?
If you feel that stories are two expansive, than consider splitting them. There are some good techniques that might help you. By splitting of stories, consider fulfilling the INVEST criterions. Another good article on this topic can be found here.
- Do you have an exhaustive DoD for your stories?
If the answer is no, than you have an insufficient sprint planning! It is of immense importance to have a well defined exhaustive DoD for each story. It helps to negotiate it with the PO. Even more important is the discussion about the DoD. Many questions and potential problems can be covered up by discussing the list.
- Is your team really committed? What is the commitment of the sprint?
It is helpful to have an overall goal for each sprint. A commitment such as: "We are going to finish all the stories selected for the sprint" is pretty much senseless. You should have something like: "With this sprint the user should be able to create and manage his profile" or it can be some nonfunctional requirement that has some impact on the user experience: "With this sprint we are going to improve the responsiveness of the GUI application." Print it onto the Story board to keep it in mind all the way long. Time to time, it can be helpful to ask the team, how they feel about the commitment.
Subscribe to:
Posts (Atom)