Before start coding, make sure you conduct a sprint planning session with the team to discuss the candidate user stories the engagement manager prepared for this sprint and create detailed estimates and tasks for them. Also take into consideration high impact / low cost changes captured in the demo and other activities that you need to do. At the end of the meeting the team should commit on the user stories to deliver in the current sprint and have obtained a reliable and clear plan to follow.

After sprint planning, and on a regular basis, stakeholders should receive information about project status. Typically this is achieved through weekly status meetings with the project sponsor and the customer’s project manager that cover project and sprint backlog, customer dependencies and risks.

If a delivered user story is not accepted by the customer it’s probably not DONE and will most likely create additional work that needs to be included in the backlog or create additional project risks. For both scenarios it’s important to capture this as soon as possible so that these can be taken into account. Typically this should be achieved by sharing a list of user stories with the customer after the Demo and getting it back with the result of the acceptance tests for each user story. If needed, help the customer to ensure he does the acceptance tests.

This should be done through a DEMO session, if possible face to face, were the work developed during the sprint is shown using realistic business scenarios. It’s critical that the attendees are engaged and provide meaningful feedback as this will be the future system they’ll use. We need to get them focused on ensuring that we leverage their knowledge and experience to make the system as usable as possible. Also it will provide you immediate information into unforeseen risks or additional changes that need to be planned.
Get an example of a Demo Script

• ATC example

Get an example of a Demo uderlying presentation

• Dubai Courts example
• ATC example

The ROLLOUT PLAN is a living document, you should build and update the rollout plan over the course of the project, we recommend that you use a shared collaborative document. Make sure that you capture any new external dependencies, business rollout needs, migrations, configuration data that needs to be configured/bootstrapped, or others that you identify at each sprint. Share it with the customer so that he can commit to his activities.

Customer trust us to be reliable in our plans. On time solution release means earlier benefits for the customer and postponing the go live date increases costs and reduces benefits. It’s the team responsibility (ultimately the EM) to ensure that all needs are meet for the GO LIVE date to be kept, in order to ensure it you need to constantly keep an eye on the roll out plan feasibility including Customer activities, re-arranging them, figuring out alternatives that do not compromise your go live date.

The delivery team should conduct a RETROSPECTIVE meeting at the end of each sprint to identify what worked and what didn’t work in the sprint that just finished. For the top things that didn’t work make sure the team has an action plan on how to improve them for next sprint.

You should continuously validate your team alignment with your customer team by requesting their feedback throughout the project delivery, ideally every sprint after the demo. This way you will be able to act and improve on the delivery process when and where needed for a final great delivery experience. Use the Customer Satisfaction app for feedback request and analysis.

This related with question 1 from the Usability checklist. The team is responsible for periodically evaluating whether the assumptions described in the Vision Document are in sync with the development of the project. It’s the team responsibility to update (ultimately the EM).

User stories for next sprint should follow the INVEST principles. Acceptance criteria has been agreed with the customer. You have representative sample data and any remaining questions regarding rules, inputs and outputs have been cleared. Details should be transmitted as conversation. Also revise the information architecture as well as refine or add new mockups to support the top user stories planned for sprint.

During the sprint and especially after the demo you should conduct usability tests to identify the top usability issues. These tests can be as simple as hallway conversation or informal tests, but should occur nonetheless.

This is the question 3.3 from the Usability checklist. Location, thinking, input and waiting costs should be minimized. Among other rules take into consideration users language, the use of attractors, smart defaults for inputs and information ordering.

This is the question 4 from the Usability checklist. There is a set of proven usability principles that, when followed, elevate the usability of any application. The application should be logically structured and supported by good navigation. Good copy plays a big role here, as it does in the user guidance and consistency. The information and functions presented to the user must be as simple as possible, by providing emphasis to what is more important.

This is the question 5 from the Usability checklist. The application’s visual appearance is the basis for its 1st impression with the users and it also plays a big role on the perceived quality of the application. The sophistication of the look&feel should be set in line with the final purpose of the application. If it is a public asset or aimed at making a lasting impact and create confidence, then extra effort should be invested.

Make sure you actually coded the functionality and integrations that support the complete user story. Test each user story against the acceptance criteria, and other tests defined in the test plan, with sample data similar to production, and recording it’s results. This may also include conducting automated or manual code reviews over a part of the code.

This should include setting up the QA environment with the sprint deployment and whatever configurations are required, populating the sample data and running smoke tests in this environment. Also a defect / feedback management process should be in place. It’s on this environment that users give feedback preferably using ECT with the project management tool.