Mendix Rapid Developer study materials
Mendix Rapid Developer study resources

Mendix Rapid Developer: Agile Development, Team Server, and Feedback Management

Mendix Rapid Developer · Work through your exam, one topic at a time.

All guide sections

Agile Development, Team Server, and Feedback Management

This domain tests how a Mendix team plans work and closes the loop with users: backlog and sprint structure in the Portal, Team Server roles and version control, and the feedback process that turns user reports into stories.

Planning in the Portal

The Portal (historically called Sprintr) holds the project's backlog. Work is broken into stories with an estimate in story points, split into tasks for individual contributors, and pulled into sprints with a start and end date. The burndown chart tracks remaining points within the sprint, while velocity informs how much a team commits to.

Team and version control

App team roles in the Portal decide who manages the team, who opens the project in Studio Pro, and who only has stakeholder access. Team Server backs the repository: each commit carries a message that can reference the story number, giving traceability from requirement to change. Branch lines isolate a risky feature until it merges back.

Feedback loop

End users of a running app can submit feedback from the app itself, capturing a screenshot and page context. Feedback items arrive on Team Server, are triaged, and can be converted into stories on the backlog; the story then flows into a sprint and eventually into commits that close it.

Worked example

Requirement: a tester reports 'the Save button does nothing on the order page'. Reasoning: the feedback item should be triaged as a defect story, estimated, prioritized against the sprint goal, and implemented on a branch if it touches shared code. The commit message references the story number so the Portal shows the change against it. Skipping triage and fixing it straight to the main line loses the link between report and change, and the fix cannot be traced for release notes.

Traps

  • Story points estimate relative size, not hours; burndown is derived from them.
  • Feedback without context (screenshot, page, user) costs triage time - Sprints and tasks are not interchangeable: tasks are not estimated in points for the burndown.