Within Nextens we work Scrum and Agile, but what is Scrum and Agile? Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems, scrum is:

• lightweight
• simple to understand
• self-organizing and cross-functional while working on a problem
• reflect on their wins and losses to continuously improve

Scrum is not a process or technique for developing software products; it is a framework within which you can apply various processes and techniques.

Agile simply means continuous incremental and iterative development through small and frequent releases. The four core values of Agile software development as stated by the Agile Manifesto are:

• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan

Scrum events which are in place are:

• Daily stand-up
• Sprint planning
• Sprint retro
• Refinement meetings

Daily stand-up

• Who: the whole team
• Where/How: Standup room or Micrsoft Teams
• What: daily 15 min meeting to syncup with the team, what did you do, why did you do it and what will you do next, are there any impediments; when finished, give the word to someone else

Use the sprint board to connect to the tasks on the board and use the "Person Filter" to show tasks in progress for the one speaking his turn

Sprint planning

• Who: the whole team
• Where/How: Meeting room or Micrsoft Teams
• What: Every 3 weeks at start of the sprint, apx 60-90 min
  • At the start of the planning check with the Delivery Manager if the goals of the former sprint have been achieved
  • Ask the Delivery Manager for goals of the new sprint
  • During Planning tasks are estimated based on expected time needed (in hours). The 'Activity' is selected to the rescource it is intended for.
  • Tasks should have a clear outcome. If not it is not ready for planning
  • (Attempt) to not have any timeboxed containers

Sprint retro

• Who: the whole team
• Where/How: Meeting room or Micrsoft Teams
• What: Every 3 weeks at the end of the sprint, apx 30-60 min, combined with Sprint planning meeting
  • Retro board should be available on the last Friday of the sprint (it is shared in the report of the former sprint)
  • Make sure to add your cards to the Retro Board. The Scrummaster is the one to create the board
  • Start by evaluating the action points from the last Retro
  • Discuss with the team how the action point(s) will be managed /adopted into the next sprint (or in the team)
  • Where possible create tasks for the chosen action points in the Backlog
  • Reporting
    • Every sprint a report is made by the scrummaster and sent to team and management
    • In this report a link to the next retrospective is included, so you can add comments during the sprint

Tip: Always have a note with retro points ready during the whole of the sprint. This way you don't forget the pain and healing points during the sprint.

Refinement meeting

• Who: the whole team
• Where/How: Meeting room or Micrsoft Teams
• What: Every week, apx 60-90 min
  • During a refinement meeting, UX designs are shared, discussed and agreed upon
  • Feature requirements and acceptance criteria are shared, discussed and agreed upon
  • Preferably during the refinement meeting, the DoR of a feature is discussed and completed, which indicates the feature is ready for development (in next sprint)

Sprint

• Don't add new PBI's during Sprint. Add them to the backlog. Connected to the correct Epic | Feature
• Unassign Person from task when done (closed)
• Less side chats - use team chat / threads for more visibility
• Focus on sprint goals. If this is not possible make it transparent to the Team why this is the case. We are here to help
• Containers should be split up to specific tasks
• Tasks in progress should have (expected/remaining effort) hours assigned

Tasks

• Tasks should have an Activity. The current used Activities are: Development, Testing and Design
• The states of the tasks mean the following
  • New: Not been picked up yet by team
  • Active: Someone is busy with it and it should be assigned to a team member
  • Resolved: Usually a development task state which means Development is done but still needs testing
  • Closed: A tester or other team member has done the checks that the related code to this task is final and ready to go to the Master.
• Bugs ready for test (for a tester) will be available in the Resolved column.
  • Keep discussions on the topic in the bug task
  • When tested ok, leave proof in the task and move to Closed

Meetings

• A meeting should have a purpose: what is the question you want to be answered and who do you need to provide input?
• 5 minutes before the meeting ends: did you achieve this, has the question been answered? Or is more time needed? Two options: to continue or reschedule for a new appointment
• Keep notes in the message / discussion section of the Meeting, This way the invitees can always come back to the important points
• All tasks and actions discussed in a (Teams) Meeting should be allocated, or added to a task on the backlog soon after the meeting
• Recording a meeting can be useful. Remember to ask permission before starting the recording

Code Reviews | Pull Requests

• Pull requests are on a User Story level
• At least one developer must approve the pull request
• At least one tester must approve the pull request (To discuss)
• Pull request comments must be marked as resolved by the comment owner.
• Unit tests should be part of PR, not the separate one. But it should go like this: code is ready => quick code review to ensure that there are no major issues with code structure and design => unit tests added => code review + merge