/
Prescriptive Feature Sprints

Prescriptive Feature Sprints

Owned by Jan Kubica
Dec 12, 2024
4 min read

Goal for the sprint: 

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

In the prescriptive approach we are still following the same good practices for Agile software development.
Sprints are 3 weeks standard.
No more than 4 sprints in a project.
Strong focus of keeping the scope without changes.
All Epics, User Stories, Acceptance Criteria, Data inputs and outputs are ready before feature sprints begin.
Delays in customer testing are a strong indication to escalations to the Steering Committee level.

Feature sprints steps:

  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

    2. The available capacity of CE and IE resources determines 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

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

  2. Daily Standup meetings

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

    2. Main activity is gone 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

    3. Discuss and remove all general impediments that might occur

  3. 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

    2. At the end of the sprint, plan a demo session for the wider customer team where the SA/BA/QA demonstrates the tickets they have implemented. Record session and share it with the customer and CSM & SDM. This is the basis for the end user documentation and training performed by the customer, and for the CSM/SDM to understand what we've implemented for the customer.

  4. Sprint retrospective

    1. Plan a joint sprint retrospective after each feature sprint

    2. Try to have everybody speak freely about things that went well, not so well, and suggest 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.

Optional special phases:

  1. Upgrade week: Two feature sprints before the end of the project, upgrade to the latest Pricefx release to be planned.
    Go-live to be on the latest release.
    Customer to do regression testing.
    Partner/Pricefx to do bug fixing if needed.
    If case of no bugs, Partner/PriceFx move on to the next feature sprint.

  2. Polishing sprint:

    1. No new configurations.

    2. Only work on spill-over items, like bugs from the previous sprint.

    3. Client finalizes all their testing, so UAT starts with a clean slate.

    4. Performance testing, optimization on selected items, e.g. logic run times, pricelist calculation times etc. 

Example timeline, based on 4 standard feature sprints:

Actions:

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

  2. Track the progress on JIRA 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 based on customer's feedback

  7. Make sure customer is testing during the agreed period of time and provides 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. Status report 

  2. Meeting minutes

Checklist for Feature sprints:

  1. All tasks are tracked in Jira

  2. Sprints are running as planned.

  3. Client performs testing, provides feedback.

  4. Client confirms acceptance in written form during and after each sprint.

  5. Weekly status reports are prepared.

  6. Project is running within defined time and budget.

  7. Testing time and bug fixing time is built-in the planning.

  8. Buffer between sprints is planned.

  9. All defects and changes are tracked in Jira.

  10. Team books time on weekly basis.

  11. The Engineering team creates release notes after each sprint. Adds those notes in public Confluence.

  12. A plan is in progress for the Go-live / cutover strategy.