3

During grooming, we usually have work items which get approved based upon the team understanding that what needs to be done? The product owner does not discuss the details of how it will be done and stops the discussion if team tries so. This applies to all work items (new UI, new API or changes to existing UI/API). Product Owner's reasoning is that getting into the details (both technical & functional) of how it will be done is something that needs to happen during sprint and discussing it during grooming is not correct. The effort estimation also happens based upon this discussion.

But during sprint planning, approved items are taken for the sprint and expectation is that if work item is approved, team should know all the details of the solution and should be able to complete the item in sprint. What happens is team spends first 2-3 days in doing the research and getting the PO's approval for the solution (UI design, key business logic clarification). Unless the analysis results in great difference in effort estimate, team is asked to complete the feature. This happens in each sprint.

I dont have a problem with putting extra effort in completing the work item. My question is regarding the process.

  1. Should the team say no in approving the item unless team understands how the solution will look like?
  2. Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.
  3. Any other suggestion as to how it can be handled in better way?
3
  • Why do you need PO's approval for the solution, if it was agreed that it's just "the details of how it will be done" ? For every question, it either defines the feature, and thus should be discussed in the beginning or doesn't define it, leaving you free to choose any reasonable solution during the sprint.
    – Peteris
    Jul 8, 2014 at 10:13
  • @Peteris we seek PO's approval for finalizing the UI design (look & feel), key points of the workflow (key interactions). Sometimes finalization of the UI design takes some time and sometimes business logic clarification uncover new scope which becomes the challenge for the team to complete it in the sprint. I was thinking if there is some way to mitigate some of this risk before approving the item or committing the item? e.g. through using research spikes?
    – jags
    Jul 8, 2014 at 10:34
  • if the key points of the workflow, key interactions aren't clear before the sprint, then what constitutes a "user story" that you'll be implementing during the sprint? To me, clarifying that feels the main (only?) work and reason for getting user stories before implementation.
    – Peteris
    Jul 8, 2014 at 11:19

4 Answers 4

4

The level of detail at the planning meeting depends a lot on the personality and expertise of the PO.

Take user interface as an example: Some product owners have strong UX skills or use UX experts outside the team. These PO's better come with a rough UX spec to the planning meeting. In other cases this skill is more present inside the team. Those teams handle the UX design as part of the implementation. The problem arises if the PO has strong opinions about the UI, but fails to communicate in advance what he wants. That is unfair towards the team.

In short, if it affects the acceptance of a work item, then the PO should not avoid the question at planning meeting.

On the other hand, you can't expect him to have all the answers prepared, the team must also think actively and give him some options to choose from.

One good way to approach this at the planning meeting, is to formulate questions to the PO as "would you accept the story if ...".

Back to your questions:

Should the team say no in approving the item unless team understands how the solution will look like?

Yes, if the PO is unable to give clarity on what he will accept and what not.

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

If for a certain work item, you all feel an iterative approach would be best ("let's see how this works, and then decide if it needs a change"). Then it is better to split it into two items. But don't think of step 1 as a prototype, make it "potentially shippable" based on current understanding of the team and PO. The PO can always define work items to improve it later.

Any other suggestion as to how it can be handled in better way?

Some teams or PO's will prepare rough UX specs (wireframe) before the planning meeting: Aim for early failure. Just enough to agree on. So that when the team commits to a work item, the scope has been clarified in advance.

2

Another way of doing it, is by splitting the session into two parts.

In the first one the Product Owner goes into the level of detail that the team needs in order to understand the requirements. No effort estimation will be done during this part. Then the PO leaves the room and the team starts with the estimation process the includes the "how it will be done".

The PO should be be available to answer questions that will come up. This is an important part of the sprint planning where you can include planning poker or any other estimation techniques. It is important that the planning will not take forever and you should have an end time where you close the session.

Anything that the team considers important should be discussed during the planning session. It is good practice. If the team leaves the room and have lots of questions it's impossible be productive. In case there are too many unknown factors then you could start a spike to research a concept and/or create a simple prototype. But it should be the exception and not the rule.

2

Should the team say no in approving the item unless team understands how the solution will look like?

No, of course not. Not knowing the implementation details leaves the team leeway in finding the simplest solution later on. This doesn't mean that discussion should be prevented, but it should certainly be limited.

Suppose for example that in the planning meeting it is decided to play a story in a certain way. Should the team be forced to use that design during the sprint? That is contrary to the agile manifesto.

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

No, this won't help the team, because prototypes have no value for your users, and therefore should have the lowest priority according to Scrum. You should only do prototypes if needed once you commit to the story, not before.

Any other suggestion as to how it can be handled in better way?

I have a few:

  1. Why is your product owner acting a Scrum Master? The roles should really be separate, and doing otherwise is generally a Bad Idea™

  2. Why are you estimating your stories two times? This should not really happen. You estimate them once, imprecisely, to get an idea of what fits in a sprint. No one should care beyond that point -- the measure becomes what you actually accomplish. Of course, there can be task estimates, but they are purposefully in a separate set of units because they should never be used to estimate what fits in a sprint, but only how much work is left.

  3. You seem to have a problem in collaborating with the PO during the sprint. For example you say the "team struggles during first 2-3 days in doing the research and getting the PO's approval for the solution". This makes no sense to me. The PO should be concerned with the end result for the user and not committed to a particular solution. They get to specify some end-to-end acceptance tests before hand, but everything that passes them is fair game -- anything else should be a new story.

  4. Your suggestion of having a prototype->story pipeline goes against collaboration and towards a separation of roles. What you really need, instead is to have PO and team collaborate during the whole sprint and talk to each other. The stories should not be designed until they are done. What you call a "prototype" should really be the story.

2
  • is it Ok to have stories specific to how the new UI should look like? Once PO agrees on the design of UI, further stories should be developed (or updated and approved if stories have already been written)? The team's challenge usually is in getting the UI design finalized and then write presentation logic. This often results changes in acceptance tests but they are modified and not moved to a new story.
    – jags
    Jul 8, 2014 at 9:10
  • No, stories should always be valuable to your users, so certainly only stuff you actually deliver to your end user qualifies. Typically this can be done in two stages: a functional stage with minimal design, in which you have a fully working feature, and a second round of design refinement. Note that each is deployable to the users and has a specific and different value for the customer. You should not do the opposite, have a "design" story and a "development" story. That's a pretty bad idea.
    – Sklivvz
    Jul 8, 2014 at 9:25
1

In my opinion your problem its here:

"Unless the analysis results in great difference in effort estimate, team is asked to complete the feature."

Another company that want to "be agile" for don't spend time in estimation and a more in depth definition of US (and that its totally ok), but there are not "agile" enough to understand the difference between an estimation and a compromise.

The SM its the one that need to explain this to the management, and if the situation where the team need to work overtime for complete features its the norm sprint after sprint the SM must put immediately and end to this nonsense and recover a sustainable pace for the team.

Having sustainable pace its one the core values of agile, finishing all included US in a sprint of course its not. In the long run the first its much more important than the second, its key to understand this.

2
  • thanks for your response. I also started feeling that this is becoming a problem. I am also not of the opinion that we must have detailed US but US should also not be vague enough which may cause effort to vary hugely when details are worked out. So I thought I will ask the question on stackoverflow for possible approaches on finding the solution. Your suggestion of giving the importance on sustainable pace def makes sense.
    – jags
    Jul 9, 2014 at 4:28
  • Try to define the US to the detail the team needs to be confortable making an estimation (not a compromise!). What level of detail?, off course this depends entirely on the project and on the team and is something only you can find. Jul 9, 2014 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.