From Requirements to Release at Moonpig iOS

 

In this post, we’ll describe the cycle from release to requirements in the Moonpig iOS team.

As an iOS developer at Moonpig you get to follow some of the most desired best practices.
iOS teams following the scrum methodology are divided into cross-functional scrum teams and work in 2 week iterations.
As well as the usual ceremonies (standup, planning, retrospective and sprint review), we also draw on XP practices like user stories, pair programming, TDD and code reviews to ensure we deliver high quality code.

From requirements to features on Moonpig iOS

Requirements don’t always come from the business. Our UX team periodically organises ODI interviews and user testing sessions to explore what our customers want. Ideas from the team are taken into consideration too – and  thanks to events like hackathons and Moonshots, we can prototype and present them to the business.

Once we have a new feature idea, it’s analysed by the team in a Story Mapping session, where everybody brainstorms user activities and tasks.  From these we identify user stories which are the starting point for our work.
The Product Owner adds these high level stories to the backlog and prioritises them.

Next the “Three Amigos” (an iOS engineer, a QA engineer and Product Owner) discuss each story. They ensure it’s clearly defined and meets our definition of  “Ready for Sprint“.  These sessions can also be attended by other team members.  Designers and UX experts bring a lot of value to this session by providing user flows and some sketches.

Three amigos
“Three amigos” 1986 ‧ Adventure/Comedy

Next, the story is ready for Technical Grooming; all team members discuss technical implementations or issues, and create sub-tasks if necessary.

During planning, the team estimates and commits to a particular set of stories and define a “Sprint goal” to achieve.
At this point the team is ready to start the development phase.

How we develop

We use GIT flow and when each feature is complete we create a pull-request against our development branch. Each pull request triggers a TeamCity job (our continuous integration tool) that runs all unit and UI tests. The code is then peer reviewed, and once approved by both a developer and tester, the pull-request is merged into our main branch.  The CI then runs all the smoke and regression tests.

Recently we implemented feature flags. This allows us to deliver faster, release new features remotely and A/B test new ideas with customers.  We can continuously merge our code and release even if a feature is not complete and we are able to activate it when ready without the need to for a new build and Apple review.

Whether we release or not, at the end of each sprint, we show our progress to the rest of the company with an internal demo during our Sprint Review.

Conclusion

Our way of working is continuously improving so check back again soon. We would like to hear from you: how do you turn user needs and business requirements into features? Feel free to leave a comment or get in touch.

Leave a Reply

Your email address will not be published. Required fields are marked *