Yes. In 'Agile' development parlance, you would have an estimation session, where the group will look at the units of work to be assigned, and determine how easy or hard they might turn out to be.
At their most objective best, everyone on a given development team can gain some insight into the work of others, and how hard it might be.
These session can also be a great way to share knowledge, as developers with different levels of experience and specialisations collectively examine high level goals.
In that, you all have a fair opportunity to either share opinions on the best way to achieve a task, or just merely learn something from someone else about tools or techniques you're unfamiliar with.
And for insightful managers, it's also a great opportunity to communicate high level aims and objective, and occasionally, also break those objectives down, transparently, and explore them.
At worse, estimation sessions can be used as a tool to bully dissenting or inquisitive coders.
Even in it's least positive guise, collective estimation sessions are still valuable. At the very least, you have the opportunity to agree, as a group, on what is, and what isn't going to take 10 or 1000 odd SLOC. You'll also have a better idea (if only slightly better in some cases), of how long that n SLOC will take to write.
It's surprising how few managers value objective estimation. But the problem I suppose, is what it does to the working relationship the rest of the company has with their software development team.
Basically, to allow a team of developers such an 'indulgence', every worker in a given business, including senior managers, have to accept that all interactions with the development team, are led by the development team.
That takes a lot of trust, and you'll rarely find that level of trust outside of a startup.
At their most objective best, everyone on a given development team can gain some insight into the work of others, and how hard it might be.
These session can also be a great way to share knowledge, as developers with different levels of experience and specialisations collectively examine high level goals.
In that, you all have a fair opportunity to either share opinions on the best way to achieve a task, or just merely learn something from someone else about tools or techniques you're unfamiliar with.
And for insightful managers, it's also a great opportunity to communicate high level aims and objective, and occasionally, also break those objectives down, transparently, and explore them.
At worse, estimation sessions can be used as a tool to bully dissenting or inquisitive coders.
Even in it's least positive guise, collective estimation sessions are still valuable. At the very least, you have the opportunity to agree, as a group, on what is, and what isn't going to take 10 or 1000 odd SLOC. You'll also have a better idea (if only slightly better in some cases), of how long that n SLOC will take to write.