Wikimedia Apps/Team/iOS/Development Cycle

< Wikimedia Apps‎ | Team‎ | iOS

The iOS team uses Kanban to manage their development process.Edit

iOS Development Process with phasesEdit

The following is an outline of the team's standard process. It is important to ensure that everyone has a shared understanding of what each phase means. There are no pre-set dates or durations for phases, as the team will discuss timing as they work and agree together on when to move from one phase to the next.

  1. Stories and Scope
    • Create initial board with epic stories
  2. Design Research
    • Comparative analysis
    • Inclusive participation plan
    • Present design proposal
    • Fill in epics
  3. Exploratory Stage
    • Engineers research and experiment with design, deliver prototypes for testing
    • Initial evaluative user testing
      • Ensure targeted audience (disability, marginalized identities, etc) testing
    • Assess accessibility requirements
    • Most major unknowns should be identified, remaining work is understood
  4. Development
    • Most functionality delivered to internal users
    • Scope trimmed to final size (remove tickets from board as necessary)
    • Stress test new features. Think of the worst case scenarios (for example, thousands of saved articles) and build debug tools that create those scenarios. Use the Instruments app to diagnose performance issues and ensure the app's memory footprint doesn't grow unbounded
    • Test with targeted audiences
  5. Feature Freeze
    • Only minor bugs and edge cases remain or added are to scope
    • Evaluative design work completed and ticketed
    • Initial QA and design review completed on all epics
    • File a ticket for performance and stress testing with Instruments. Explore the app for regressions.
    • File tickets for release management.
  6. Code Freeze
    • Do pre-release smoke test and beta
    • Monitor beta release crash reports for at least three days before another beta release
    • Remove all “nice to haves” from the board
    • All tickets are well defined
    • Only new tickets come from QA or tester feedback
    • Create a new branch from develop named as the version number for the release; any changes to the release are done as pull requests/patches targeted to this branch
    • Finalize marketing messages and materials, update app store assets
  7. Release Call
    • Final check with engineers
    • Actual release happens
    • Release notes publicized
    • Documentation updated
  8. Release


These meetings ensure that the team maintains regular communication and has time for planning and board upkeep.

Name Frequency Duration Description Goals Attendees
Board Grooming once a week 25 min Team meets to clean up the currently active release boards or the backlog.
  • Triage tasks and/or
  • Groom tasks
  • Product Owner
  • Engineers
  • Designers
  • Tech Program Mgr
Weekly Planning once a week 50 min Team meets to talk about a variety of different topics suggested by Product Owner, e.g., QA, work on current features, organizational updates.
  • Check in with QA
  • Sync up on current work
  • Document action items
  • Product Owner
  • Engineers
  • Designers
  • QA (optional)
  • Tech Program Mgr
Standup on days when other meetings don't happen 15 min Team meets to exchange quick status updates.

Everyone but Facilitator answers three questions:

  1. What have you been up to since the last standup?
  2. What do you expect to be working on until the next one?
  3. Do you have any blockers?

After giving their update, each person chooses who goes next by saying the other person's name.

  • Share what you've worked on
  • Share what you'll be working on
  • Share what's blocking you
  • Product Owner
  • Engineers
  • Designers
  • Tech Program Mgr
Task Sync once a week 50 min Team meets to sync up on what they're up to and decides if any tasks on the current release board need to be discussed and/or estimated. The first part of the meeting is a classic standup. Part of the meeting is dedicated to reviewing user feedback - team members take turns gathering user feedback before the iOS Task Sync and share the findings with the team during the meeting.
  • Share what you've worked on
  • Share what you'll be working on
  • Share what's blocking you
  • Establish if there's enough work until the next meeting
  • Review the Needs Engineering Sync & Ready for Development columns on the current release board
  • Move tasks from Needs Engineering Sync to Ready for Development, if applicable
  • Estimate tasks, if needed
  • Groom (split, link, tag) tasks, if needed
  • Report on the chore wheel
  • Product Owner
  • Engineers
  • Designers
  • Tech Program Mgr
Retrospective every 2 weeks 30 min Team meets to discuss topics proposed by team members, mostly process-related.
  • Discuss what's working well
  • Discuss what could be improved
  • Establish next steps to implement change
  • Product Owner
  • Engineers
  • Designers
  • Tech Program Mgr