Developing features for BBC iPlayer mobile apps
Project Manager, TV and Mobile Platforms
Hi, I’m a Project Manager, working in the mobile BBC iPlayer team. I work alongside the Product Owners, developers and testers, to ensure we regularly deliver updates and improvements to the app for the audience to enjoy.
BBC iPlayer on iPad
The challenge is always to develop the next most valuable feature, and release it to the audience as soon as possible. This focus has resulted in the team developing and delivering a number of features over the last 6 months - 30 day programme availability, support for iOS 8, Android L and the new accompanying devices, S4C and Radio 1 channels, better quality playback on Android to name a few, as well as a whole host of bug fixes and performance enhancements.
So how have we done it?
Stories and Epics
Every new feature starts with the idea, which the Product Owners express in the form of user stories. These follow a simple format – ‘As a user, I want some functionality, So that I can receive some benefit’. A recent example of this was the following story for the Audio Described content we made available in v4.4 of the app:
As a person who watches and listens to Audio Described programmes
I want to be able to easily find Audio Described programmes
So that I can enjoy the best content the BBC has to offer me
As the stories are often written from the view point of the end user, the size of the story can vary from being a small, well understood requirement to a much bigger story which needs more discussion to fully understand what is being requested. These bigger stories are known as epics. The lead developers are given early sight of the stories and advise on which epics need breaking down into smaller stories or where further detail is needed. Once broken down, they are presented to the wider team in a workshop, where the team collaborates to order the stories until the feature can be thought of as a series of ‘5 day challenges’
Audio Described content in BBC iPlayer
5 Day Challenges
The concept of a ‘5 Day Challenge’ is slightly different to more conventional estimation techniques such as story points or just estimating in terms of days/weeks. Rather, the team asks itself what usable functionality can it deliver in 5 days. The team reviews the stories and groups them into a number of 5 day challenges. The challenges themselves are then reviewed, and the team discusses how different ordering of the challenges would affect the development of the feature. For example, given two challenges, X and Y, does it make more sense to do X first, and then Y? Or can we take a bit of X and a bit of Y, and deliver that as one challenge? Which ordering gives the value to the audience quicker?
This collaboration between the whole team allows everyone to leave the workshop with a clear understanding of how the feature will be developed, what will be achieved at the end of each challenge and how long we believe the feature will take to complete.
The shared understanding gained from the workshop is brought forward to the 3 Amigo sessions we run (see Jitesh Gosai’s thorough explanation of 3 Amigos here). Rather than going through the whole feature up front, we define enough scenarios to get the challenge started, and set up subsequent 3 Amigo sessions when needed.
Once the team starts the challenge, they continue until it is complete, with regular, often daily, demos throughout the development. This gives the Product Owners the opportunity to tweak the requirements or even to sign off that the challenge has been met early, allowing the team to move onto the next challenge.
As per Kanban principles, work is pulled in only when there is capacity within the team. Once brought in, the developers and testers work together to write automated tests (more information can be found here), develop the feature and start manual testing of the work as soon as there is something testable (see Steven Cross’ excellent post about manual testing here). This often means that the feature is being tested as it is being developed, allowing potential bugs to be identified early and thoroughly squished. Combined with the regular demos, this process results in fast feedback loops, ensuring all parties are kept abreast of progress and any possible issues.
The Radio 1 channel is one of many features implemented using the 5 day challenge approach
The process of 3 Amigos, development and sign off from Product Owners is repeated until the team believes that the feature is at a point where it can be released. In some cases, this might mean signing off the feature for release before all the stories have been completed – as long as there is sufficient value in the work completed so far and the users have the core offering of the feature available, the team will look to release the app. In such cases, the remaining stories are re-assessed and if they are still required, are worked on for future releases of the app.
When the app is ready for release, we run a round of regression testing to ensure that it continues to work on a range of supported devices and operating systems. This sees the app being put through its paces, helping to ensure that the changes made haven’t inadvertently altered existing functionality. As each release often includes more than just new features – for example, bug fixes, performance enhancements or changes to the services the app relies on – we take a risk based approach to regression testing, looking at those areas of the app that have had the most changes. Although our testers lead this, it is a collaborative effort with all members of the team picking up devices and going through the test runs. This quickly gives us the confidence that the app is of high quality, and can be released to the app stores. Given that the turnaround around time in the various app stores can be between 1-2 weeks, the team looks ahead to the next version of the app, defining and pulling in new features to work on.
I hope you’ve found this post to be an interesting insight into the way features for BBC iPlayer mobile apps are developed. If you have any questions, please feel free to leave a comment below.