4

I need to know about product development planning in a particular scenario. I planned my sprint and executed it, and then I submitted the product URL for feedback and received a response from my Product Owner. In this case, in which sprint (current sprint or next sprint) should I implement the feedback? What is the normal procedure for this in agile development?

2

I think Aziz provided a solid approach.

In the scenario you described, it sounds like you have obtained feedback from your PO at the end of your sprint.

If so, then the answer is simple - you have no time remaining in the current sprint and will have to estimate and prioritize the feedback for consideration in future sprints. Agile does not call for extending a single sprint to work on a feature or feedback.

To help one better manage the wide variety of feedback, it is one's responsibility to have user acceptance criteria (UAC) defined for user stories in a sprint.

I hope this helps.

2

Feedback items eventually become part of the product backlog by either revising or adding new items in the backlog. These have to be prioritized by the Product Owner before the team pulls them into a Sprint/Iteration Backlog. So to answer your question:

in which sprint (current sprint or next) should I implement the feedback responses

Feedback gets implemented based on the priority set by the PO. If PO wants a feature/story to be completed before the feedback items then the team will implement the feedback in a future sprint.

All the feedback items added to the backlog need to be estimated. Depending on the estimation, team may come to the conclusion that they may have to add one or more sprints to the project plan. If this is the case then it should be clearly communicated to the PO as early as possible because that will help the PO in properly prioritizing the backlog.

An effective and efficient Feedback Loop is very important during Agile Development. However, strong and potent management of this feedback is equally critical, otherwise we'll have an unorganized and unmanageable product backlog in our hands. Not all the feedback items needs to go into the backlog. PO has a very significant responsibility to analyze the feedback and control what goes into the backlog. One of the tools that PO can use is the MoSCoW prioritization technique, where each item can be categorized (or further broken down) as follows based on the product/project goal:

  • M - Must have
  • S - Should have
  • C - Could have
  • W - Wont have

Wont have items also need to be documented and assigned a status of closed, so that we dont loose sight of those and can be tracked. These items can be those feedback items which are not relevant to the product or are not cost effective to implement at this time.

Some reference about the use of MoSCoW in agile:

However, this is just one of the available tools. There are other prioritization techniques which can be employed too. The goal is better prioritization of the product backlog.

  • Moscow is an anti pattern in scrum and agile in general... – Sklivvz Dec 14 '13 at 22:42
  • @Sklivvz would be nice to have a reference on that. I would also like to update my knowledge. Thanks – Aziz Shaikh Dec 15 '13 at 18:32
  • Moscow is a RAD technique (not agile) -- en.wikipedia.org/wiki/MoSCoW_Method – Sklivvz Dec 15 '13 at 18:43
  • @Sklivvz the same page also says "MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus can be on the most important requirements, and as such is seen as a core aspect of rapid application development (RAD) software development processes, such as Dynamic Systems Development Method (DSDM) and agile software development techniques." – Aziz Shaikh Dec 15 '13 at 18:46
  • Backlog items are sorted in order of priority (mountaingoatsoftware.com/agile/scrum/product-backlog), not in 4 categories – Sklivvz Dec 15 '13 at 18:47
1

TL;DR

You're missing some defined meetings that would make this all much clearer. Specifically, you appear to be skipping:

  1. Sprint Review, which is the correct place for end-of-sprint feedback.
  2. Backlog Grooming, where the Product Owner can work with the team to modify the user stories in the Product Backlog based on the Sprint Review and other factors.

Feedback can be incorporated at any point in the Sprint cycle, but feedback that generates new goals or user stories are always scheduled for future sprints, unless the Product Owner invokes Early Sprint Termination with an immediate return to Sprint Planning.

Your "Feedback" is a Review

While many user stories are conversational placeholders which facilitate communications between team members (and sometimes stakeholders, other teams, or end users), this is quite different from a review. If you are having a conversation with your Product Owner about ongoing work during the Sprint, this can help the team make small corrections to help keep the Sprint Goal on track. This is one of the many reasons that a Product Owner should sit with the team, and be available to the team throughout the Sprint.

However, making small corrections that don't impact the Sprint Goal or significantly change the user stories accepted into the Sprint is not at all what you're talking about in your post. When you say:

I planned my sprint and executed it, and then I submitted the product URL for feedback and received a response from my Product Owner.

you are describing a situation where the feature-delivery for the Sprint is completed, and the team is demonstrating the features for the Product Owner and the stakeholders. This is the Sprint Review, where the team compares the results of the current Sprint against the Sprint Goal defined during the most recent Sprint Planning session.

This is the organization's opportunity to review the progress of the project, provide feedback about the project or features to the team, and to identify potential user stories for the Product Owner to prioritize based on the work just completed. This is one of the defined inspect-and-adapt meetings which underpin the Scrum framework, and skipping it or using it improperly is definitely a Scrum anti-pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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