How to hold a project kick-off / requirements gathering meeting for a job interview?

Question

I've got the dream job interview of a lifetime tomorrow, and I need to facilitate a 45-minute requirements gathering and planning meeting for a software application they think up. It will be me standing in a room with a 'customer' and a developer. They're expecting user stories, requirements, etc. by the end of it.

I'm very well-versed in Scrum, but have never held a project kickoff or planning meeting before. Any links, YouTubes, steps, or advice you could give me? I've tried my best Google-fu to find a mock 'project kickoff' meeting to watch or read about, but I have failed. I appreciate it! <3

Answer 1

Interesting problem. I'd be a little concerned that an interview setting is not necessarily a realistic microcosm of a real project. You're going to enter with much less understanding of the problem and 'customer' than you might expect to have in a normal professional engagement. However since you seem to have some idea what a successful outcome would look like this should be manageable.

Everyone has their own idea what a good kickoff looks like so if you can frame yours in a context appropriate for the company you want to join that's probably better. All I can offer is my experience as a contractor at Carbon Five.

Your question refers to a couple of different activities; requirements gathering, project kickoff, story planning. I'll often spend 45 minutes on each of those so I would want to prioritize which of these you actually need to cover.

Normally I would start with a kickoff to explain the process my team uses, how it works, and what is expected/required from everyone participating especially the customer/project owner. That's probably not going to give you a good chance to highlight your abilities in an interview though so you may need to hope that can be taken as assumed knowledge or under a vague description: "this team will be using an agile iterative process to build your product, we're not going to plan everything today but we should leave in a good position to plan each feature as they come up."

I would focus on requirements gathering activities. Since you'll have a customer and developer present you can aim to produce some actionable stories but I would make it clear that in an initial meeting many of those are likely to be epics and need to be broken down in future conversations unless the problem is very simple. You should be able to get everyone to participate in a planning activity and give yourself a good opportunity to demonstrate your ability to lead an interactive discussion and discovery of the product the client needs.

I would try to start by sketching some very lightweight personas as the customer explains the problem. Just enough to have a reference for who you are building this for and what constraints you understand them to have. Normally this is something I would try to have beforehand but I think it's worth 5 minutes to show a shared understanding of who this product is for and if there are multiple user personas to agree to focus on one. (I've found the style Lane Halley describes in Personas for Coders useful.)

Given some idea who your user is I would try to build a simple experience map. In 15 minutes you should be able to sketch out the activities your user performs which interact with the product and the different touch points involved. This should be a good chance for the developer to help identify external systems you'll need to integrate with and for the customer to reveal interactions outside the bounds of the product you control (e.g. forwarding emails to other people).

Finally I would use the activities identified in that experience map to start writing some high level stories and defining some initial milestones for the project. I find that a story map is a good way to start organizing these sort of stories and shuffle them into functional (rather than temporal) milestones. This is also a chance for you to demonstrate writing good INVEST stories with a customer and developer.

I would certainly be out of time at this point but hopefully you can block off a few minutes to discuss next steps like detailed estimation of the first sprint or milestone and to ask about the process the interviewers normally use.

Good luck.

Answer 2

It is hard to know exactly what they intend with this interview mock project, but if I were to do something like this (as the interviewer) I would primarily be looking to see the candidate's strategy for ensuring they have an accurate understanding of the customer's problem and priorities. As a secondary benefit I would be able to see how the candidate communicates with a customer: phrasing, tone, making assumptions vs. asking non-biased questions.

Since a lack of problem definition or initially solving the wrong problem leading to rework are such common problems I would be looking for a candidate that can avoid those issues, but that is just my bias.

On a related note, I would advise you to focus on what you already know and are at ease doing. In my opinion "cramming" and trying to remember new skills during an interview will lead to stress and nervousness which will probably impact your ability to respond freely during the interview. I think it is more important to appear at ease during the interview as that conveys deep competence at what you are discussing; if necessary you can be open about what areas you do not have as much experience in but state that you are looking forward to the opportunity to get more experience in those areas.