Music can lead to motivation, inspiration, and new connections. Starify is hoping to allow its users to not only listen
to the music they choose but also share the music they create.
As Starify is a new music sharing app there are many features to add, improve, and change. As well as current features
that need to be refined. Therefore, here is our playbook defining our 4 plays that will lead to the success of our
platform and the happiess of the platforms users.
Who is it that is doing the development of this service behing the scenes. The engineers and
developers of this service need to be well defined. As well as any increase in staff that may
need to occur
Who are the stakeholders that are supporting us? The sales and marking team that will have a say
in the features that are being shown interest and marketed.
Who is this service for? The users and their stories. The users should be getting the most out of
this service. This includes streaming and creating music. As well as using a user empathy map to
learn more about the users and what features they may want in the future.
Checklist
Define our team and any requirements needed to join the team
Establish a solid connection between the team, stakeholders, and the users ASAP
Prepare for the growth of our team and get new team members up to date
Keep the satisfaction of the user at the center of our focus
Key Questions
• How will the company prepare for growth with the growing demand for features?
• How will the engineering teams and stakeholders communicate effectively?
• What are the users wants or needs for the service?
As the popularity of Starify grows so will the number of developers and engineers needed to developers
and maintain the service. Starting off with only 5 engineers we are looking at increasing our staff to
10 by the months end. As well as having a prediced growth for 30 by the following month, and 100 by
the end of the quarter.
At the start of the project there will be a greater need for engineers with more experience. As the
number of engineers increases there will be a greater pool of knowledge thus allowing for less experienced
engineers to join the team. Requirements for this team would be knowledge in software engineering and
in the language that the service is being coded in.
Communication is key to any successful team. By focusing on clear communication between the Starify
developers, and sales and marketing teams. Our sames and marketing team have already informed the
developement team that the increase in interest has lead to multiple ideas for new features to add
to the Starify service. This clear communication has allowed the developement team to let the stakeholders
and marketing teams know how they are doing on improving and maintaining current features to in the
future allow for these new features to start on developement.
These coversations will be covered in the daily scrum meetings, reminding the engineers what the stake holders
and users want. As well as having the team leads to communicate what their teams can and can not do to the
sales and marketing team. Documents will have dates mentioned clearly so all teams know relase and due dates,
to ensure marketing teams are marketing the right feature(s) at the right time.
Aguably the most important group of people would be who the service is for, the users. Therefore, the usere
empathy map must be made and well defined for the team. The empathy map is located below.
This map shows the features that the users would like to see in the service as well as what features they
would be most likely to use. Engineers are encouraged to keep this map and the users in mind to create
easy to use features and features that the users will actually use. These features will be more defined in a later section.
What is it that we are designing and how are we designing it. Before working on or changing a poduct
said product must be defined. Having as set vision and goals for the project reminds the team why this
project is being made and what goals are. The vision is to make a music streaming and creating service.
The goals are to keep the user satisfied with our service and to improve the quality of our service.
Checklist
Define what the project wants to accomplish
Define features, how they will work and be used
Key Questions
• What are the goals of the project?
• What are the features?
• Will the user use the defined features?
The Startify services intends to be the best, well rounded, and for everyone music service. Startify views
itself being a users first choice for both music streaming and content creation. Users will no longer need to use
any other apps to find and enjoy the newest music made by the biggest and newest artists.
The goals for the Starify service are as follows:
1. Allow the user to stream music
2. Provide user with specially generated music recommendations
3. Allow users to create their own playlists
4. Allow music creators to upload their music
5. Keep a system in place to avoid users uploading someone elses music
Feature areas can be divided into client, ad generator, creation, and upload tool
Client
There will be a variety of clients for the starify service, to allow for all kinds of users to enjoy the music
they love.
For the user on the go there will be an app for Starify. This app will be on apple and android devices. There will
also be a desktop app for MacOS and Windows OS. These apps will alert the users on updates that are available and be
updated separateke.
There will also be a brower option for users. The user will have to log in each time they wish to use the service
on a browser and thus maybe a less effecient way of enjoying the service, but allows the user to freely use the service
on any device through the browser.
Ad Generator
Ad generation is how Starify earns money and pays its developers. Depending on the users most listened to artists
products that that artist is known to support will play for the user. For the most part ads will be generated at
random but always family friendly. There will also be a large variety of ads generated for the users to try and
avoid repetative ads that annoy users.
As the service increases there will be an add free optiton of the service that will require the user to pay a certain
amount per month
Creation
Music creators will be given many tools to attempt to get other users to listen to their music. Users that are
also registered creators will have a different UI. They will have a different app as well to view or change
their status as a creator.
Creators will fill out their genre and artist similar to them. They will also have something resembling a hashtag section
which they can tag up to 15 tags that other users can search for and find this new creator. Starify will aslo have playlist
generated for its users that are new creators that have tags similar to the artists that the user already has. These tags
will also have an explicit tag again to ensure that users know if a certain song is family friendly.
Upload Tool
The upload tool will be quick and easy while also quickly scanning the file to ensure that it is not another song being
reuploaded by another user. It will also scan for explicit content and warn the user uploading the content that their
content will be tagged as such.
After defining what will be developed it is time to develop it. Developing Starify includes defining
the software engineering activities, the process framework, and how changes will be made.
Checklist
Define the SQA activities that will be used
Define the framework of the process
Define how the team will go about implementing change
Key Questions
• What will be the SW engingeering activities will be used to define the process?
• What kind of data will be gathered?
• How will the team go about implementing changes to the process?
The process for software engineering activities will include SQA activities, security, process
improvement, and data gathering.
SQA Activities
Risk Analysis
Security
The security of our system is a top priority. Security reviews will occur at the begining and end of each sprint.
This will ensure that any code that is implemented at the end of a sprint is secure. All engineers will be required
to have DUO authentication on their work computer. And users will have the option to use duo on their account.
Data Gathering
The project metrics that will be gathered will be the backlog size, and the defect rates.
• Currently there are many active features that need to be revised and worked on
which are taking up much of the backlog. Our sales and marketing team have also informed us
about the interest in new features which will soon be added to the backlog as well.
By gathering data on the backlog size we hope to ensure that the backlog is staying at a
reasonable size. We also hope to see the rate of items removed from the backlog per sprint
remain constant and at a reasonable rate. Also protentiallty increasing the rate of items
our of the backlog as the number of engineers increases.
• The rate of defects will also be monitored as depending on the size of the defect
it could increase the items in the backlog or delay their completuion. Gathering data on
the defects will also allow us to see if there is a need for more time or engineeers
to work on a feature or backlog item before its release. The Defects will be measured through
its arrival rate hoping to keep the amount of defects that arise low.
The process metrics that will be gathered will be the time to realease of a feature, the number of work hours and defects per engineer.
• The time ro realease if each feature will be monitored. This will help monitor whether a feature
with more time allocated to it resulted in less defects and thus helping manange the time that is
allocated to a feature.
• The number of work hours will be monitored to ensure that the team is as efficent as possible. If a
sprint had more work hours allocated to it then it should result in a greater amount of backloged
items to be worked on.
• The number of defects per engineer will be monitored to ensure that no one engineer is lacking in
provide quality work. This will also allow us to ensure that we have engineers with the proper skills
requred for their posirion.
Process Improvement
Depending on the data gathered mentioned in the previous section, the process will constantly be trying to improve. The
following image is an example pf how the process will imrpove through the projects developement.
The process framework chosen for the Starify service is scrum. Scurm has a prioritzed backlog
which will be usefufl with how many features need work done, and also those features that the sales
and marking team is wanting to promote. Scum also suppots constant changes and updating which is
useful for Starify's growing team and feature list. Unfortunately the grownth of Starify and the
Starify development team will make using scrum a bit difficult but with communication and team
splitting the Starify engineers can overcome this.
Changes will be handled by noting all the data that was gathered from the previous iteration. Then this will be compiled in
a power point presentation which will be shown to the team. Then the team will take time coming up with possible solutions.
These possible solutions will be brought to a change review board which wil consist of a member from each team.
This is our current play, as Starify grows there is no telling how big our team will get or how many features the
Starify service will have. This process is solid but not set in stone and we at Starify look forward to change
and improvement. If there is any confusion on this playbook contact a team lead or the creator of this playbook
at [email protected].
