# Guidance on selecting projects :8ball:
It is unlikely that you will build a functional MVP from scratch after graduating (outside of side projects or founding your own start up :eyes:). This is because you will be joining companies that already have defined users, a tech stack and code base, and depending on size even separate teams for UX, DevOps and Quality Assurance.

Therefore it's a really important opportunity to learn about full stack development that we should make the most of. :books:

## What makes a good project? :bulb:
- **The problem and user(s) are clearly defined**: the four of you already have a similar idea of what the project is about and who it will help as well as having users available to conduct research with
- **You will be able to manage the scope of the project**: you need a functional MVP after two weeks of building, including unforeseen delays. Can the project be scaled back if necessary, and still provide something valuable to your users?
- **It will probably require using technologies you're not familiar with**: this is the ideal time to be researching and utilising new technologies - just remember to factor in time to learn them!
- **It has lots of positive feedback**: this is not a priority over your own feelings as a group towards each idea, however feedback from the wider cohort can help to see an idea's potential.

### Bonus :100:
- **Something similar already exists in the open source community**: this means you can make a meaningful comparison with some real world code

## Tech for Better Selection :raised_hands:
All the considerations above should be kept in mind for TFB selection alongside the following points. A yes to each question probably means its a good choice.
- **Proximity to users**: can the Product Owner arrange research and testing with real users?
- **Expectations**: is the Product Owner flexible about what the solution is? Are they aware we will build an MVP and some features may not be included?
- **Responsiveness**: Is the Product Owner available to engage throughout the project?
- **Vision**: Does the Product Owner have a clear idea of what they'll do after building an MVP?

## Strategies for deciding as a team :triangular_ruler:
We recommend that people don't push for their 'own' ideas to be used - at this point, all project ideas are owned by the cohort. Feel free to remind your teammates of this. It might help for the team to nominate a facilitator for this process - and not to nominate oneself. This person is not necessarily the project's Scrum facilitator.

### Democratic method - voting :raising_hand:
Everyone gets some number of choices, e.g. five, of projects they think would suit their team's strengths and learning objectives. You take the group's top three choices, and facilitate a discussion if there are any tied choices in the selection, using the above criteria to come to a satisfactory solution.

**Pros** quick, common sense approach
**Cons** prone to deadlocks, and people getting stuck on own preferences

### Sociocratic method - elimination :+1: :-1:
Take it in turns to suggest an idea that you feel doesn't suit your team's interests, strengths and/or learning objectives, briefly outline your reasons (<30s). Take a temperature check from everyone (thumbs up strongly agree, thumbs down strongly oppose). Address any concerns from people who strongly oppose, and either agree to remove from the shortlist or revisit in a later round - make notes of concerns for future discussion. Repeat until you have a top three.

**Pros** everyone's voice is heard, all ideas considered, more informed starting point
**Cons** can take a long time, choosing to remove someone's idea could be taken personally