When to process feedback on the deliverable of the last iteration?

Question

My team and I are working with iterations of two weeks (trying to use our own version of Scrum) and we try to deliver a new version after every iteration.

After an iteration we let the stakeholders test our new version on a staging environment and they send us feedback. This feedback will be processed and the smoothed version will be deployed to production after we get an OK from all stakeholders.

This way of working is working fine sometimes, but in some iterations we are experiencing problems plannings wise. At the start of our next iteration, it is still unclear how many feedback we will get on our deliverable, so we can't really estimate the time needed to process the feedback in our iteration.

Can someone give us some tips about how to incorporate a correct feedback loop inside or workflow? Maybe we can deliver the deliverable two days before the end of our sprint, so we know how many feedback we have on the moment we start our sprint? I also thought about a workflow in which we let the stakeholders test the features during the sprint, so we can process the feedback in the same iteration we developed the feature.

Answer 1

I'm a big fan of a continuous feedback loop rather than making it stick to a schedule.

My suggestion would be to:

• Deploy frequently to your staging environment (whenever you have a stable build).
• Inform your stakeholders of anything new and significant in the staging environment (perhaps with a newsletter or updated wiki page).
• Accept feedback at any time (perhaps using an appropriate tool, email address or just verbal feedback).
• Have the Product Owner regularly update the backlog with any items arising from feedback.

Let the stakeholders know that not all feedback will be immediately incorporated. Educate them that the timing of their feedback and how significant the new work is will impact on when the work gets done.

At first this may seem chaotic, but with careful thought your team can become good at dealing with change in a continuous and controlled fashion. The nature of feedback is inconsistent, so you may as well build a process that handles this inconsistency.

Answer 2

It seems a little surprising that one of the answers hasn't covered this, but: do you hold a review meeting at the end of the iteration?

Scrum and XP both include this meeting to address the challenge you raise. This meeting gets all of the stakeholders there using your app and giving feedback at one time and place before your next sprint. It also gives the team the opportunity to clarify the feedback if it is confusing.

Answer 3

If you are following pure Scrum then Sprint Review can help you. Only sprint review is the event of Scrum when Increment (developed software/feature) is ready for stakeholder review and stakeholders are allowed in this meeting.

Sprint Review:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

A software product development is ongoing process and will never complete till the existence of the product. So, all such kind of feedbacks can be a part of next sprint, when you have feedbacks from client.

Answer 4

There are a few possibilities to tackle this situation.

Using Scrum:

You can work in alternated iterations.

• During Iteration i, you work on functionality foo.
• At the end of iteration i, the client assess foo and you start iteration i+1 working on functionality bar
• At the end (or during) iteration 1+1, you get the feedback about foo and plan changes on it for i+2

Using Kanban

If your team is mature enough and can constantly deliver value before iteration ends, restricting your delivery cycle to the end of the iteration may be hampering you. This is one of the alternatives I've seen some very seasoned team adopting:

• Team uses iterations as a high level 'guideline' but work is done based on each feature - having constant deliveries to production, even several deliveries to production in a single day
• This way, as soon as the feedback is obtained, if the feature is ready for deployment, you can deliver it. No Sprint contraints.

IMMV. Experiment both approaches and define which one fits better your case.

Answer 5

Analysis

Based on the information you presented, your biggest challenges are that:

• Delivery and deployment currently depend on out-of-band testing.
• Your delivery and deployment are tightly coupled, and dependent on resources outside your team.
• The scope of testing, and the amount of work necessary post-testing to meet the Definition of Done are undefined.
• You are treating all work arising from testing as work-in-progress.

You are certainly correct that better feedback loops are essential, but you need to modify your workflow to generate the feedback sooner without adding never-ending scope creep to your list of problems.

Recommendations

You have two basic options for improving your workflow:

1. Move acceptance testing into your Sprints.

   With this workflow, you collaborate more closely with testers or end-users throughout the development process. This will generally entail working with testers from the beginning of each Sprint to define acceptance testing criteria (e.g. Cucumber tests or other BDD/ATDD framework), and deploying features to your QA or staging areas as early as possible for testing. You'll also need to ensure that your Definition of Done includes the testing workflows.

2. Decouple delivery from deployment.

   With this technique, you use feature toggles (defaulting to off) or environment gates to deliver your increment. Whether you deliver continuously or once at the end of each Sprint doesn't matter all that much, provided that you are validating that the behavior in production is free of regressions and breaking changes as part of your Definition of Done.

   Deploying tested features to production, or toggling a new feature already delivered to "deploy" it, becomes separate from your Sprint. The deployment work is treated as new work for a separate operations team, or as new work for a future Sprint by the Scrum team. In an ideal world, such features are independent and can be managed in parallel. However, they can also be pipelined sequentially if the organization is willing to accept the cost of "stopping the line" when there are problems, or queue delays caused by sequencing issues or intermediate failures that cause sequential work to back up.

You can do either or both. In all cases, work that meets the Definition of Done but that takes effort or attention from the team must be treated as new work in order to avoid continuous scope creep. This is the part that teams often struggle with, regardless of the workflow. That's why a solid Definition of Done and a test-first approach are so important to a successful agile delivery process.

Answer 6

Maybe we can deliver the deliverable two days before the end of our sprint, so we know how many feedback we have on the moment we start our sprint? I also thought about a workflow in which we let the stakeholders test the features during the sprint, so we can process the feedback in the same iteration we developed the feature.

Either of these would be good improvements to your current practice, if you can make them happen. Having stakeholders test features during the sprint would be preferable, because it makes the development-feedback loop as tight as possible, and allows stakeholder acceptance to be part of your Definition of Done. Ideally you would do both, in order to get integration testing completed as part of the sprint, too.

In addition (or in the meantime), I would change the presumption that you can't plan sprint N+1 until all feedback has been received for the sprint N increment. Reverse that assumption: during sprint N+1, you'll work feedback received prior to the sprint planning, but anything else will have to wait til the following sprint. (It's only two weeks, after all.) Presumably you have a product backlog that you can use to fill out the sprint, if necessary.

Good luck!

Answer 7

Scrum-compatible:

1. Give access to new functionality sooner. When a task is ready - deploy and ask stakeholders to check it out.
2. You probably have meetings with stakeholders within sprint already - you can use them to demo unfinished functionality. Lets you find out that your direction is wrong even before Devs finished current tasks.

Incompatible with Scrum:

3. Don't let Scrum and its sprints suffocate you. If it doesn't fit - don't force it upon the team. It puzzles me that with Lean, ToC, CD practices available people still use Scrum. Be Agile - build the process that makes sense for your team and your project. "Individuals and interactions over processes and tools", remember?
4. Get rid of The Big Planning. Instead of planning for the whole 2-week period you can prioritize tasks for the next 3 weeks and then reorder them as you get feedback.