From PvE & Priorities to a plan. Part 2: MVP & planning

Size: px

Start display at page:

Download "From PvE & Priorities to a plan. Part 2: MVP & planning"

Darleen Gordon
7 years ago
Views:

1 From PvE & Priorities to a plan Part 2: MVP & planning

2 Today s goals Decide on the Minimum Viable Product (MVP) for your detailed design Decide on the MVP for your demo Develop your backlog Start designing

3 Minimum viable product (MVP) Part of the Agile methodology Allow teams to build measure learn What is the minimum product required to allow you to meet your learning goal(s)? The user can use it and be able to experience the key benefits so you can get feedback You can build with the time, resources (and finance) you have

4 Example: Dropbox MVP Source:

5 Deciding your learning goals (10 min.) What do you want to learn from your first version of your product? What are the main benefits (see your product statement)? What do you want to test to see if it works? What are the biggest risks factors to the success of the product? Write these down as learning goals

6 A question for those of you developing the student app Who decides if they will use your app? The student? The VMBO teacher? This will be important to you MVP Yes you want to test the student experience, but does the student decide if they are going to use it? Think about the teacher too!

7 Defining your MVP (20 min.) Which user stories are essential to allow you to achieve your learning goals? These should be in your MVP Use MoSCoW to categorize all your user stories on a flip-over Must have MVP Should have Critical to eventual project success but maybe not time critical (due to work arounds, etc.) Could have Nice to have (think about experience & ROI before dismissing) Won t have Not critical, low ROI, ill-defined

8 Product poker Feedback on your MVP

9 Form groups Organize yourselves into groups of 3 All of you should be working on the same interface Give each person a set of planning poker cards

10 Product poker The goal of planning poker is to reach a consensus In this game the poker cards are used to give your estimate of the importance of a user story to the MVP based on your understanding of the concept and the learning goals 0 = not important, 1 = lowest importance and 21 = highest,? = I need more info Do not worry about accuracy (it isn t possible it s an estimate)

11 Instructions (3 x 15 min.) Each group member has a 15 minute round to get feedback (set a timer as they start) 1. They should explain their concept and learning goals and then their first user story from the MVP 2. Each member of the group should then place a card that represents their estimate of importance for that story on the table at the same time (including the person getting feedback) 3. If all are the same write the number on the post-it and move on to the next story If there are different numbers then the highest and lowest should explain their reasoning everyone should listen and not give their opinion (you can ask questions) 4. You should then all vote again Continue voting on one until there is a consensus or the person getting feedback decides to move on (they should write their priority on the post-it)* * In real planning poker you would continue until there is consensus

12 Reorganize your MVP (10 min.) Make any changes to your MVP based on the feedback you have received Move the MVP to another flip-over and add the functionality and tasks post-it to each one

13 Pauze (15 min.)

14 Planning poker Estimating your effort

15 Planning poker In this game the poker cards are used to give your estimate of the effort required to design and develop the user stories in your MVP This time the cards represent an estimate of hours required to complete (don t use 0,? = more info please) Again do not worry about accuracy (it isn t possible it s an estimate)

16 Instructions (3 x 15 min.) Each group member has a 10 minute round to get feedback (set a timer as they start) 1. They should explain the functionality and tasks to deliver the first user story from the MVP 2. Each member of the group should then place a card that represents their estimate of how long the story will take to deliver on the table at the same time (including the person getting feedback) 3. If all are the same write the number on the post-it and move on to the next story If there are different numbers then the highest and lowest should explain their reasoning everyone should listen and not give their opinion (you can ask questions) 4. You should then all vote again Continue voting on one until there is a consensus or the person getting feedback decides to move on (they should write their hour estimate on the post-it)* * Again in real planning poker you would continue until there is consensus

17 Check your MVP (10 min.) Total up the estimate of hours for the stories in the MVP How many is it? Do you have enough time? Use +/- 40 hours as the number of hours you have If you have not got enough then what can you do? Work more hours (be careful) Remove things from your MVP (what?) If you have more what can you add? Should haves? Could haves?

18 Next steps If you want to continue playing planning poker to finalize your MVP Check your story priorities Play planning poker with each other to work out what should be in your demo and how much effort this will take Start working on the first user story today!

There are 3 main activities during each Scrum sprint: A planning meeting where: the Product Owner prioritizes user stories in the product backlog

There are 3 main activities during each Scrum sprint: A planning meeting where: the Product Owner prioritizes user stories in the product backlog that need to be implemented during the sprint the Team