How to properly conduct a feature development meeting?

Question

I am a Product Manager, under me I have about 10 developers, UX designers and marketers. Marketers research about the demands of features, UX designers providing UI mockups, and develkopers write code.

Now, we want to do our feature development monthly meeting (sprint) in a more structured manner ( previously, feature priority is decided in a somewhat adhoc manner, we want to change this). The goals of the meeting are

1. To set the priority ( urgent, important, normal, not important) of each feature
2. To make sure that everyone knows what to do for this coming milestone after the meeting is over.

But given that we have 10 people on the team and usually, we have more than 50 features to discussed, I afraid that the whole meeting will drag on for a long time. Also, for the second step, I would need to allow time for everyone to check their schedule, as not everyone is fully available to work on the features ( some would need to fix bugs, provide technical supports etc), so if I ask them to do this in the meeting, then there will be some lull time and disrupt the flow of the meeting.

Is there any well-established meeting procedure that is fitting to my situation above?

Answer 1

Stop wasting time!

The main point I want to make is that the more people you have in a meeting, the more time you are wasting. Whenever you are discussing something not directly relating to employee X, you are wasting employee X's time.

Why is this a bad thing? Obviously there is a direct cost (assuming you are paying employee X for his/her time!) but there's also an indirect one - you are demoralising employee X. Every time he/she is up against a tight deadline, or having to work overtime, they are going to think about the wasted time they spent in that meeting when they could have been achieving something.

So, keep your meetings as small as possible. You do this by organising people into teams. Think of a team as the set of people who need to be involved in order to implement a task. This might be specific people, or it might be "two developers and one UX designer". One person can be in more than one team, and you may well need to create different teams for each feature.

If 2 teams need to work together - e.g. team A can't start their feature until team B finishes theirs. In this case try to get one or two representatives from each team involved instead of bringing the whole team in.

Deciding priorities

Ultimately the product is being developed for a customer (or customers), and it's the customer who decides which features are most important. Your marketers are the ones dealing with the customers, so it's their job to find out what features the customers need/want next and assign priorities to those features.

To decide how to prioritise features, your marketers need to define the requirements, which they can then use to get an idea of how much development/design time is going to be required for each of them. This is one of those meetings where you get representatives from each team together.

Your devs/designers might need to have a discussion with their respective teams to come up with a decent estimate, so allow space in your scheduling for that. I'd suggest making these meetings fairly frequent - either as and when new features are thought up, or on a weekly/bi-weekly basis.

The other important thing to consider is that some features depend on other features. If feature A is a prerequisite for feature B, then feature A has to come before feature B in the priority list.

Another point here is that bug fixes should be treated as features here. It's up to the customer to decide if they thing new feature A is more important than fixing that niggly bug with existing feature B! This should also simplify your scheduling.

Planning for the next milestone

With your prioritised list of features (with time estimates) this part should be pretty straightforward. Basically, just take the next achievable feature* off the top of the list until you've filled up people's time!

If you find that you can't do the top item on the list because it a required person/team already has a full schedule, leave it for the next milestone and find the next achievable feature.

Get everyone to give you copies of their schedules and you should have all the information you need in order to do the milestone planning on your own. Just remember to leave some time for dealing with the unexpected!

Further reading/where to go from here

I've barely skimmed the surface here. I strongly recommend you spend some time reading up on different development methodologies and working out what would suit your team's situation best. Agile development is the "in thing" (there are various types - e.g. Scrum and Kanban are popular) but it might not be the best fit for your team.

The final point I'd like to make is not to change things too quickly!

Answer 2

I would advise you to split up your team of 10 and make two or three teams out of them.

Think divide-and-conquer. Meetings with 10 people tend not to be optimally productive, but work better with maybe 3-5 people.

The development meetings (as you call them) might not need all people, and are probably not the right way to make sure everybody knows what to do for the next milestone. Those development meetings should be where the decision on what to do is taken, after a long discussion.

After the meetings with each team is done, you should have (for each team) a list of tasks that should be done within the sprint. Maybe it's better to just share those. You can even make a whiteboard or kanban board that everybody can see.

Thinking about this, however, it seems to me that the basic problem you are having is with the organizational structure, with how to structure a team of 10, and not necessarily with Scrum or sprints.