After having worked in a few different regulated contexts, I find it difficult to believe that you can't automate at least portions of the work needed to satisfy your compliance requirements. In my experiences, the claim that you can't is based on reading too much into the regulations and standards and relying on common misinterpretations rather than actual ...
Only Peripherally On-Topic
First of all, this is an opinion-generating question about something other than project management, and would normally be off-topic on two fronts. However, the notion of satisfaction with deliverables is somewhat on topic, and so I'll confine my comments to that aspect.
Don't Abuse the Net Promoter Score
According to this site:
I would propose setting up in-house a mini-site that mirrors all the (important) functionality of the live site.
This way you can Release & Test to your test site as often as you want. You can get continuous feedback from an internal testing team. You could even propose to your customer to review select interim releases and provide feedback.
I think the 1-5 survey is particularly prone to bias. Not only do you have the normal bias of people being surveyed wanting to please the surveyor (and thereby being more likely to, say, answer '4' instead of '3'), you also have to deal with it being a smaller scale. One person's 'happy' is another person's 'neutral', after all.
It would probably be a ...
I don't know if it is a standard, but probably the best way to assess productivity is to track the number of deliverables completed and accepted by the client. The advantages to this approach are:
Truly objective and simple to measure. Something is either done and accepted by client or it is not. And you avoid the risk of something sitting around being 90% ...
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 (...
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.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. ...
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 ...
The gold standard is "in person"
Here is a good depiction of the effectiveness of different modes of communication from Alistair Cockburn:
One of the twelve principles behind the Agile Manifesto is:
The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
I have managed teams ...
The stakeholders may not have a choice, but they will still have an opinion.
I'd phrase the question in terms of how satisfied they are.
"On a scale of 1 to 5, how satisfied are you with the product?"
"On a scale of 1 to 5, how accurately do you feel the product meets requirements?"
More useful than a rating answer is direct feedback:
"Name an example of ...
I am a big fan of NPS. However, it has a specific purpose and it sounds like your need does not fit that purpose. I would look back at exactly what it is you want to know. Some questions you should consider in identifying the right things to ask:
1) Do you want to know about the overall opinion about the product or a specific impact it has (satisfied vs it ...
Even though you have an annual release cadence, you would still have sprint deliverables for your scrum team. Your Product Manager would have defined these sprint deliverables at the start of your PI.
Use these sprint deliverables as a checklist (a fully set up functionality is not required for a demo). To improve your feedback loop, set up a sprint ...
Whilst feedback is vital, they are not the same thing.
A cadence is a regular rhythm of activity. For example, in Scrum, most ceremonies have a once-per-sprint cadence. I'm guessing they use the term "cadence" instead of frequency because they want to remove the time-based association of frequency and instead allow for more event-based occurrence. For ...
My approach would be to send the list first and get the ranking (1 to 10) order, sit and order the requirement based on the ranking and call for a meeting with all participants, discuss and go for a ranking negotiation that enhances the understanding of what customers really want.
I suggest using the MoSCoW prioritization; e.g. ask them these questions for each feature:
Would we have problems if this feature doesn't exist in the product? (y/n)
Yes: Can we have a workaround for the problem? (y/n)
No: How much relative value does it add? (1 to 10)
For a single answer, YY is a must-have, YN is a should-have, and N is a could-have. For ...
From my experience, I recommend the Buy a Feature game.
This works best if you can get all the stakeholders in the same room, so that your stakeholders have a chance to discuss their opinions.
Putting a virtual "price" on features helps you to adjust the prioritization to the relative effort that it takes to implement a certain feature.
One way would be to set up a quick survey - there are sites that let you do this for next to nothing.
Rank each feature between 1 (must have) to 5 (hardly necessary).
Or else "Yes, Maybe and No"
Else you could send each a spreadsheet and use a clever macro to merge the results.
I think you'd get more accurate results if you ask them to choose their top 5 ...
Give access to new functionality sooner. When a task is ready - deploy and ask stakeholders to check it out.
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 ...
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 ...
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.
There are a few possibilities to tackle this situation.
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 ...
A) Include more aspects into estimation
One thing that might help you estimate each task for effort (sheer amount of work), difficulty (amount of thinking) and risk/uncertainty (how much can go wrong). Then let those assessments guide your estimation.
B) Keep your estimates but adjust them
The FogBugz approach. Estimate normally, record how long it ...
What is the main target for this survey? As I understood, you want to assess your teammates, but maybe you want to realize how well is a scrum for you?
The target involves what type of questions should you make. But for both reasons I advise below actions:
Use the Likert Scale
Avoid the feelings in questions (well, bad, good or something like this), use ...
According to this source, we can read the following
What is Net Promoter Score® (NPS)?
Net Promoter Score (NPS) is defined as a metric for determining the
state of a customer’s loyalty and satisfaction with a brand or
Classification of customers based on NPS survey response:
The data pulled from this response is an indicator of their ...