Goal for the sprint: 

Deliver, test, demo defined increment of function; customer has tested and accepted the results.

A typical timeline will consist of a number of feature sprints, ranging from 2-6 sprints. In these sprints the user stories will be planned. For projects where there is a polishing sprint planned, this means that this should be on top of the configuration sprints; no new configuration user stories should be planned in the polishing sprint. This sprint should be reserved for handling spill over items like bugs, allowing the customer to finish all unit testing, and to do performance tests. Two feature sprints before the end (including the polishing sprint), an upgrade to the latest Pricefx release should be planned, so that we go live on (as much as possible) the latest release. During this week, the customer should do regression testing.

The process steps during the feature sprints:

1. Sprint planning meeting

1. Before each feature sprint, have a sprint planning meeting. All defined user stories (defined from requirements perspective, that have a design and an estimation) can be planned in the next feature sprint

   1. The available capacity of CE and IE resources determine how many user stories can be planned in the next sprint. Do not over plan sprints as this sets wrong expectations; better is to under plan and pull in additional user stories when possible

   2. The Product Owner on the customer's side determines the priorities; the Pricefx PM determines when the sprint is full

2. User story refinement sessions

1. During the feature sprints, user stories from the backlog can be refined. This means requirements can be detailed (but not extended, else they need to be re-estimated) and the Pricefx SA can add a design.

   1. These user stories can be part of the next sprint planning meeting

3. Daily Standup meetings

1. It is strongly encouraged to have daily standup meetings with the combined team (Customer plus Pricefx)

   1. Main activity is go over the active sprint board from right to left. Start with the customer testing column and make sure that all assignees know there is a ticket assigned to them and that they are picking them up. Go all the way to the in progress items by the IE/CE and make sure everybody understands the actions assigned to them and the there are no impediments

   2. Discuss and remove all general impediments that might exist

4. Sprint demo meetings

1. Don't wait until the demo meeting to move tickets to the customer for testing; move then directly after we've completed them so the customer can jump on them and finalize their testing during the feature sprint

   1. At the end of the sprint, plan a demo session for the wider customer team where the SA/IE/CE demo the tickets they have implemented. Record this session and share with the customer and CSM. This is the basis for the end user documentation and training performed by the customer, and for the CSM to understand what we've implemented for the customer.

5. Sprint retrospective

1. Plan a joint sprint retrospective after each feature sprint

   1. Try to have everybody speak freely about things that went well, not so well and suggested improvements. Avoid finger pointing, try to understand from all parties what they struggle with and how we can help each other. Create a culture of continuous improvement.

The optional phases:

1. Upgrade week: two feature sprints before the end (including the polishing sprint), an upgrade to the latest Pricefx release should be planned, so that we go live on (as much as possible) the latest release. During this week, the customer should do regression testing. Pricefx should do bug fixing if needed. If no work involved for us we can work already on the next feature sprint.

Please see this example timeline, based on 5 feature sprints:

Open

Actions:

1. Follow the development of the assigned to sprint user stories

2. Track the progress in Sprint board

3. Make sure team is logging time on daily basis

4. Check with customer the progress at standups

5. Prepare a Demo for the developed functionality during the week 3

6. Document all bugs and changes in JIRA on base of customer feedback

7. Make sure customer is testing during the agreed period of time and provide feedback in JIRA

8. Schedule a retrospective

9. Plan next Sprint together with customer

10. Assign change requests/bugs to the upcoming sprints and access the impact on timeline/budget

11. Work already on the go-live / cutover strategy well in advance of the go-live. Part of this is requesting the production instance - this needs to be done latest about 30-45 days before the go-live.

Artifacts:

1. JIRA Project

2. Status report 

3. Meeting minutes

4. Project Controlling Tools

5. Acceptance protocol

Checklist for Feature sprints:

1. All tasks are tracked in JIRA.

2. Sprints are running as planned.

3. Customer performs testing, provides feedback and signs off the results of the sprint in written form.

4. Weekly status reports are prepared.

5. Project is running within defined time and budget.

6. The testing time and bugfixing time is included into the planning.

7. The buffer between sprints is planned.

8. All defects and changes are tracked in JIRA.

9. You team is booking time on weekly basis.

10. The customer confirm acceptance in written form during after each sprint.

11. Your engineering team creates a brief release notes after each sprint and add those in public Confluence.

12. You have a plan to work on the go-live / cutover strategy and started working on this (including a plan when to request the production instance)