Planning

Before the actual Sprint Planning and Sprint Development begins the most important part for the project delivery is the planning part. The purpose of the planning is to ensure that all or at least the most critical features, use cases, user stories and the delivery roadmap are ready, and the project can continue as smoothly as possible.

The Planning includes:

1. Review product / delivery roadmap (Product / Delivery team)
2. Confirm Sprint schedule / capacity (Scrum Master – appointed EM / TL)
3. Groom product backlog and update user stories
4. Propose a sprint goal and backlog before the sprint planning meeting
5. Set planning meetings (Who should be at it / what happens during each meeting?)
   • Planning Day 1: Present sprint goal, team split
   • Planning Days 2-3:  Review each user story and describe what tasks need to be done
   • Planning Day 4/5:  Get verbal commitments from everyone in the team.

Definitions

The basic definitions used are explained as follows.

Definition of READY

• An item is immediately actionable by the Team
  • Item is defined and reviewed
• An item has the necessary Acceptance Criteria for it to be considered as doable
• An item has all the necessary descriptions written down and exceptions if applicable

Definition of DONE

• All development has been completed
• Functionality has been tested by the developer
• Unit tests have been completed
• Integration test have been completed
• New business functionality satisfies the acceptance criteria
• All features have been tested with modern browsers; Chrome, Firefox & Safari
• Regression tested in Chrome, Firefox & Safari in test environment
• User Story has been reviewed by EM / TL and EM / TL accepted all open issues if any

User Story

• A template for writing effective US
• Definition: “As a <user role> I can <activity> so that <benefit>”
  • Make it concrete, small, and testable. Example: “As a job seeker I can search for jobs” is too vague and could be split into several US: “As a job seeker I can search for jobs by attributes like location, salary range, job title, company name and date the job need was posted”
• Context and Value
  • Business context and reasons for the requirement are clear
  • Map US as a step in the business process diagram

Acceptance criteria

• [Beginner] – Simple description on how functionality should work.
  • Example: “Only show last 2 emails sent to the customer” “When pressing ‘resend email’, show example of email sent”.
• [Advanced] – Given <precondition> When <scenario> Then <expected result>.
  • Example: - “Given that the customer hasn’t received any emails yet, when agent opens dashboard, then ‘no previous emails’ message is displayed”

Guidelines

• User Stories are a set of steps in the business process and must be clearly mapped in its flow
  • The Sprint goal must represent an end-to-end process that is meaningful and can be demonstrated to business as part of the final solution
  • The business process frames the User Story’s definition, business value and expected user experience.
  • This context provides the right level for communication and understanding over what is being built and its impact on other process steps
  • The first conversations during the shaping phase take place around the process – The US details are refined next, based on these conversations.
  • Recommendation: maintain the business process / activity diagram(s) with the US mapped and use it always as context for US definition

Agile implementation

Prepare the Sprint Backlog

• Break down user stories in technical tasks:
  • Because User Stories are informal descriptions of features, the dev team needs to break them down into the actual tasks needed to make that feature work (create tasks as sub-issues and keep them associated with the respective (parent) user story)
• Remember our definition of “done”:
  • This is the snapshot of what our software will look like at the end of the sprint. It is important that the people doing the work (the developers) and those inspecting it (the product owners / QA and other stakeholders) are on the same page
• Clarify the acceptance criteria:
  • Just like we need to know what “done” looks like on a sprint-level, we need to know what is acceptable on a task-level to call it complete. This is usually up to the Product Owner / Engagement Manager to decide; however, it is good to have a conversation around it as a team.
• Development team agrees on capacityfor the sprint:
  • While the Product Owner / Engagement Manager can help clarify the selected items in this sprint, an important part of Agile development is that it is the responsibility of the development team to decide what can get done in a sprint. The development team agrees on our capacity and designs a system of how we are going to get the work done - self-organizing and breaking the work planned for the first day down into small units.

Backlog structure

Sprint Planning and Review

Sprint Planning

• Sprint Planning is an event where the team determines the product backlog items, they will work on during that Sprint and discusses their initial plan for completing those product backlog items.
  • Occurs on the first day of each sprint
  • The entire team is involved in the planning session
  • The team members forecast how many User Stories / Backlog items the team is able to complete during the sprint according to the estimated size of the items
  • Includes the planning for Code Review in each sprint (core team and an expert outside the core team)

Sprint Review

• Sprint Review is an event where the team goes through what has been finished and what has not been finished during the sprint.
  • Occurs on the last day of each sprint
  • The entire team is involved in the review session
  • The team makes a go/no-go decision for a possible release
  • The even includes a Sprint Retrospective where the team goes through and learns about the experience from the past sprint and uses that information to improve the upcoming sprints. Sprint Retrospective can also be, and usually is, an entirely separate event from the Review Session.

Sprint Daily and Weekly

Sprint Daily

• Sprint daily is, as the name suggests, a daily recurring short event where the development team goes through the daily status of the delivery and the team
  • Occurs every day of each sprint
  • Usual duration 10-15 minutes, maximum 30 minutes (depending on the team size)
  • Each team member shares what he/she has been doing since last daily, what he/she is doing now and what he/she is going to do until the next daily.

Sprint Weekly

• Sprint Weekly is, as the name suggests, a weekly recurring event where the team goes through the situation of the sprint and the backlog. This event is also intended to work as a grooming session, and it provides a needed transparency and overview for the business stakeholders also.
  • Occurs once per week in each sprint
  • Involves at least the TL / EM and business stakeholders
  • Provides a view for the steering group and business stakeholders on the progress of the delivery and enables prioritization efforts

Documentation, communication and reporting

The requirements and needs for documentation, communication and reporting usually varies between different Customers quite a lot so the ways of working will be specified and agreed separately between the delivery partner and the customer. The delivery partner will be more than happy to provide its expertise, best practices, and experiences on selecting the best possible ways of working to ensure great, efficient, and transparent delivery.

There are default ways of working in every project delivery that the delivery partner provides and if nothing else is agreed between the Customer and the delivery partner, the default ways will be used. The specifications of the default ways of working are below:

Documentation and communication

• The OutSystems Platform documentation can be found from OutSystems website
• Using the best practices of adding comments to the code written into the application
• Other documentation efforts are the responsibility of both parties to upload and maintain when applicable
• Backlog, User Stories, Iterations etc. related to the delivery will be stored in the Project Management tool Rally or Jira where an access can be granted according to the requirements of the Customer.
• By default, the main communication channels are, but not limited to, PM tool Rally or Jira, email, and Slack

Reporting

• Memos / meeting minutes from Major Scrum Ceremonies if something is decided which cannot be seen in the product / project backlog tool
• Memos / meeting minutes from Steering Group meetings
• Report of the used hours and euros of the delivery team monthly, if needed the frequency can be increased.