Shaping WIP

Shaping is creative and integrative. It requires combining interface ideas with technical possibilities with business priorities. Shaping requires collaboration with all roles which may involve during the development process. Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows. We can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason, we have two separate tracks: one for shaping, and one for building. During the sprint cycle, the teams are building work that’s been previously shaped and the Products are working on what the teams might potentially build in the next sprint.

Activity Overview

Shaping

The shaping layer should be done before the sprint start.

1. WIP Product Brief:
   1. Essential Output: PRD (product requirements document).
   2. Outcomes & Value derived:
      1. To draft PRD
      2. Backlog review
      3. PRD has been shared to Product lead, Team Lead, Designer and QA to get any feedback.
      4. All feedback on the PRD has been fixed and shared to the team during planning meeting.
2. WIP Design: On Review PRD
   1. Essential Output: Design product (Figma UI design).
   2. Outcomes & Value derived:
      1. Draft design has been shared to the Product team, Team lead and QA to get any feedback.
      2. All feedback on the design has been fixed and share to the team during planning meeting.
3. Task breakdown:
   1. Essential Output: Development plan.
   2. Development plan is made for making notes of broken-down tasks and the details, so that the team knows better what to do in the ongoing sprint.
   3. Development plan would be done upon task breakdown session Broken-down tasks are not in detail yet now, it can be seen that there are some tasks which look like we would just need to update part A, in fact it causes change(s) on part B and C. It makes the engineer works a longer time than the first estimation.
   4. Development Plan Template: Devplan Template
   5. Outcomes & Value derived:
      1. The engineer team understands the project well enough to make informed decisions on the development planning strategy.
      2. Engineer team to scope of the project, what can be done in the sprint, and give a clear estimation for each assigned task.
      3. The engineer team members would hold a meeting and discuss upon how the tasks would be done, like for example whether the task needs a payload update, so they would need to plan how would the payload be, where would the changes be.
4. WIP Test Strategy
   1. Essential Output:
      1. Test plan
      2. Test scenario & test case
   2. Outcomes & Value derived: 1.
5. WIP Sprint Planning: