Scrum Activities
PAGE 1
iOS Application Development
Scrum Activities
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 2
LEARNING OUTCOMES By the end of the unit, you should be able to: ● Explain what a sprint is and outline its typical length ● Create a workflow that outlines the process of Scrum ● Describe the various activities of the Scrum process ● Explain what is needed before the first sprint ● Prioritize user stories for a sprint
VOCABULARY ● ● ● ● ● ● ● ● ●
Sprint User Stories Product Increments Sprint Planning Standups Sprint Reviews Retrospectives Product Backlog Defining Priority
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 3 Foundation of Scrum: Sprints Scrum is a collection of activities (including meetings), documents, artifacts, and team workflows. To best understand the Scrum process we first need to define a key element of the Scrum process: a sprint. Sprints are time-bound activities, wherein the development team works to complete a set collection of small goals. They are like milestones: the team completes specific parts of the application by a certain time and shows it to the client. Sprints can be anywhere from 1 to 4 weeks in duration. Generally shorter sprints are preferred to longer sprints because the goal is to get the application working and in front of the client as quickly as possible. We mentioned that each sprint has a set of small goals. In the development world, we define these goals as User Stories, which are specific functions the application needs to have. Together, the collection of user stories define the entire application. The goal of the development team is to complete all of the stories in the sprint backlog by the end of the sprint. When they have done this, they have produced what is a referred to as a product increment. Each product increment is a recognizable, visibly improved, operating subset of the final product, meeting understood acceptance criteria. The team puts that product increment in front of the client at the end of this sprint for feedback. It’s important to note that the completion of a sprint means that all the user stories of that sprint are bug free and can be demonstrable to the client. In fact, the product should be shippable to end users if the client felt the app was ready. So, each sprint produces an app where all the assigned user stories for that sprint are complete, functional, and polished—no rough drafts accepted!
Scrum Meetings There are typically four meeting types in Scrum: 1. Sprint Planning: Identifying what user stories to work on. 2. Daily Standups: Review progress on user stories of the sprint. 3. Sprint Reviews: Review the work that was completed and demo to the client if necessary. 4. Retrospectives: Team members reflect on the past sprint.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 4
Preparing the Project Before the first sprint begins, the Product Owner for the team gathers information from the client to understand what they are expecting for their final product. A key deliverable the product owner creates before the first sprint is the Product Backlog, which is a complete list of user stories that define the final application. Again, this is the full list of user stories needed to build the application. Once the product owner has all the user stories, he or she will prioritize them for the team.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 5
The Product Backlog is a living, breathing list that will continue to grow and shrink over the course of the product development. Typically, at the beginning of a project that Product Owner will create as many stories as possible, but understands that they cannot guess every possible user story until development progresses. Sometimes stories may even be removed if the Product Owner later realizes a feature is no longer needed. Example Our development team was asked to build an app that, once a user logs into their account, they watch an animation of a pink unicorn running around in circles with flames coming out of its nostrils. The client has waffled back and forth between a unicorn or a goblin, but has finally decided on the unicorn.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 6 Gathering all User Stories for the Backlog: Let’s assume there are only three user stories here. They are: ● The user will have the ability to create an account ● The user will be able to login to access his or her account ● The user will be able to watch an animation of a pink unicorn with flames coming out of its nostrils Prioritizing the User Stories for the Backlog: Our driving question when prioritizing stories is: What would be the best way to prioritize these stories and consequently the order they are implemented for the benefit of the client and the efficiency of the team? For this example, some people might say that the account setup story would be first because, in the final product, a user cannot get the unicorn animation unless they have an account. However, the better answer would be to prioritize the unicorn animation first, since the client was debating between this and the goblin. The client might decide that after seeing the unicorn animation they want to take the app in a completely different direction. If this were the case, we would want to find this out as soon as possible in the development life cycle. The account creation and login process is already well known and carries low development risk. This helps protect the team from spending too much development time implementing all the account setup and login functionality only to find out later that it might not even be necessary given that the unicorn animation just wasn’t something that people wanted. Defining priority Figuring out the priority of the backlog is not for the faint of heart. It takes a lot of experience working with clients to be able to forecast pitfalls and see user stories that raise red flags. However, a good starting point would be to identify any stories that meet any of the following: ● If deleted or changed, it would significantly increase the amount of work needed to build the app ● It is vague or there is little detail from the client (for example, a client may say “I’ll know it when I see it”) ● Is unusual or unique to this particular project (for example, the ability to recall the second-to-last line in every Walt Whitman poem is unusual or unique, while having a login screen is not) ● Is something the client wavered on in a meeting (this is a red flag that the client doesn’t know what they want, so it’s best to get some feedback on it immediately)
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
iOS Application Development
Scrum Activities
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 2
LEARNING OUTCOMES By the end of the unit, you should be able to: ● Explain what a sprint is and outline its typical length ● Create a workflow that outlines the process of Scrum ● Describe the various activities of the Scrum process ● Explain what is needed before the first sprint ● Prioritize user stories for a sprint
VOCABULARY ● ● ● ● ● ● ● ● ●
Sprint User Stories Product Increments Sprint Planning Standups Sprint Reviews Retrospectives Product Backlog Defining Priority
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 3 Foundation of Scrum: Sprints Scrum is a collection of activities (including meetings), documents, artifacts, and team workflows. To best understand the Scrum process we first need to define a key element of the Scrum process: a sprint. Sprints are time-bound activities, wherein the development team works to complete a set collection of small goals. They are like milestones: the team completes specific parts of the application by a certain time and shows it to the client. Sprints can be anywhere from 1 to 4 weeks in duration. Generally shorter sprints are preferred to longer sprints because the goal is to get the application working and in front of the client as quickly as possible. We mentioned that each sprint has a set of small goals. In the development world, we define these goals as User Stories, which are specific functions the application needs to have. Together, the collection of user stories define the entire application. The goal of the development team is to complete all of the stories in the sprint backlog by the end of the sprint. When they have done this, they have produced what is a referred to as a product increment. Each product increment is a recognizable, visibly improved, operating subset of the final product, meeting understood acceptance criteria. The team puts that product increment in front of the client at the end of this sprint for feedback. It’s important to note that the completion of a sprint means that all the user stories of that sprint are bug free and can be demonstrable to the client. In fact, the product should be shippable to end users if the client felt the app was ready. So, each sprint produces an app where all the assigned user stories for that sprint are complete, functional, and polished—no rough drafts accepted!
Scrum Meetings There are typically four meeting types in Scrum: 1. Sprint Planning: Identifying what user stories to work on. 2. Daily Standups: Review progress on user stories of the sprint. 3. Sprint Reviews: Review the work that was completed and demo to the client if necessary. 4. Retrospectives: Team members reflect on the past sprint.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 4
Preparing the Project Before the first sprint begins, the Product Owner for the team gathers information from the client to understand what they are expecting for their final product. A key deliverable the product owner creates before the first sprint is the Product Backlog, which is a complete list of user stories that define the final application. Again, this is the full list of user stories needed to build the application. Once the product owner has all the user stories, he or she will prioritize them for the team.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 5
The Product Backlog is a living, breathing list that will continue to grow and shrink over the course of the product development. Typically, at the beginning of a project that Product Owner will create as many stories as possible, but understands that they cannot guess every possible user story until development progresses. Sometimes stories may even be removed if the Product Owner later realizes a feature is no longer needed. Example Our development team was asked to build an app that, once a user logs into their account, they watch an animation of a pink unicorn running around in circles with flames coming out of its nostrils. The client has waffled back and forth between a unicorn or a goblin, but has finally decided on the unicorn.
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
PAGE 6 Gathering all User Stories for the Backlog: Let’s assume there are only three user stories here. They are: ● The user will have the ability to create an account ● The user will be able to login to access his or her account ● The user will be able to watch an animation of a pink unicorn with flames coming out of its nostrils Prioritizing the User Stories for the Backlog: Our driving question when prioritizing stories is: What would be the best way to prioritize these stories and consequently the order they are implemented for the benefit of the client and the efficiency of the team? For this example, some people might say that the account setup story would be first because, in the final product, a user cannot get the unicorn animation unless they have an account. However, the better answer would be to prioritize the unicorn animation first, since the client was debating between this and the goblin. The client might decide that after seeing the unicorn animation they want to take the app in a completely different direction. If this were the case, we would want to find this out as soon as possible in the development life cycle. The account creation and login process is already well known and carries low development risk. This helps protect the team from spending too much development time implementing all the account setup and login functionality only to find out later that it might not even be necessary given that the unicorn animation just wasn’t something that people wanted. Defining priority Figuring out the priority of the backlog is not for the faint of heart. It takes a lot of experience working with clients to be able to forecast pitfalls and see user stories that raise red flags. However, a good starting point would be to identify any stories that meet any of the following: ● If deleted or changed, it would significantly increase the amount of work needed to build the app ● It is vague or there is little detail from the client (for example, a client may say “I’ll know it when I see it”) ● Is unusual or unique to this particular project (for example, the ability to recall the second-to-last line in every Walt Whitman poem is unusual or unique, while having a login screen is not) ● Is something the client wavered on in a meeting (this is a red flag that the client doesn’t know what they want, so it’s best to get some feedback on it immediately)
MOBILE MAKERS ACADEMY 223 W Erie, Suite 4NW, Chicago, IL 60654 www.mobilemakers.co
© 2016 Mobile Makers Academy, LLC
