Skip to content

Product development process

Jump to bottom
Tobias Schubotz edited this page Jun 11, 2020 · 3 revisions

Team 🎳

  • Software engineers 🛠️
  • Product managers 🚀
  • UX/UI designers, UX researchers 🎯
  • QA engineers (?)

Cycle

We are doing sprints with a length of 2 weeks (10 working days).

Week Day Activities Sprint A Activities Sprint B Activities Sprint C ...
1️⃣ Monday
Tuesday (Estimation ⚖️), Sprint planning 📑
Wednesday
Thursday
Friday
2️⃣ Monday Work on requirements ✒️
Tuesday Work on reqs ✒️
Wednesday Work on reqs ✒️
Thursday Reqs final at 3pm ✒️
Friday QA 🚨
3️⃣ Monday Release 🚢
Tuesday Sprint review 🚦, retro 🎢 (Estimation ⚖️), Sprint planning 📑
Wednesday
Thursday
Friday
4️⃣ Monday Work on requirements ✒️
Tuesday Work on reqs ✒️
Wednesday Work on reqs ✒️
Thursday Reqs final at 3pm ✒️
Friday QA 🚨
5️⃣ Monday Release 🚢
Tuesday Sprint review 🚦, retro 🎢 (Estimation ⚖️), Sprint planning 📑

Meeting outside of sprint cycle: Gnosis Safe Team weekly every Tuesday.

Activities

Work on requirements ✒️

  • Product managers 🚀 define requirements
  • Product manager prioritizes tickets
    • Always make sure that tickets are prioritized properly.
  • Software engineers 🛠️ add technical details and split epics up into tech tasks
  • UX researchers perform research and tests
  • UX/UI designers 🎯 refine screens
    • Prototypes on Invision
    • Later stages on Zeplin
  • Software engineers 🛠️ discuss technical details
  • The entire team 🎳 thrives for clarifying open questions and thriving for adding details to requirements
  • The requirements should be final from product the week before a start of a sprint at Thursday 3pm.

Estimation ⚖️

  • Estimate implementation effort for features
  • Run by Software engineers 🛠️
  • Doesn't have to happen Tuesday as indicated in the table above. This is just the last possible moment.

Sprint planning 📑

  • Team 🎳 commits to a set of features
  • Potentially reprioritize tickets based on estimations
  • Ideally no technical discussions

QA 🚨

  • The specific QA process is to be defined.
  • Types of QA that make sense:
    • Feature QA
    • Release QA
    • Regression tests

Release 🚢

  • Requires release notes and potentially updated store assets
  • Mobile apps are release to the store
  • Further activities to be defined, e.g.
    • Internal announcement on Slack
    • External accouncement on Twitter

Sprint review 🚦

  • Meeting for the entire team 🎳
  • Review features and completion.
  • Demo current state and new features.

Retro 🎢

  • Meeting for the entire team 🎳
  • Reflect on performance and collaboration during the last 2 weeks
  • Decide on process changes.
  • Specific retro format to be defined

Team weekly

  • Team meeting with the entire Gnosis Safe team 🎳
  • Independent of the sprint activities

Tickets and agile board

Epics

  • Epics for features reside in https://github.com/gnosis/safe/.
  • Epics describe product features to be implemented.
  • Epics are generally created by the product manager.
  • Epics are refined by the product manager together with the rest of the team.
  • Epics in the Product backlog column are not prioritized and work in progress.
  • Epics in the Specs to review column are sorted by priority and ready for feedback and development.
  • Epic labels
    • Android/iOS 🏗: Epic is in to do or implementation is in progress on Android/iOS - added by product manager
    • Android/iOS ready for QA 🙏: Epic is marked as ready for QA by devs on Android/iOS - added by dev team
    • Android/iOS ✅: Marked as done by QA on Android - added by QA
  • Epic is closed when it is done on both platforms - moved/closed by product manager

Technical tasks

Bugs

  • Bugs are created on the respective client repo.
  • When a ticket is part of the current sprint, it is re-opened. When it was part of a past sprint, a bug ticket is created instead.

Wiki home

Wiki home

Clone this wiki locally