views:

230

answers:

6

I'd like to know whose responsibility in the team it is to take the spec (produced by the business analysts) and itemize it (tickets and sub-tasks) in the issue management system (e.g. JIRA) (for the perusal of the developers).

I have a feeling it depends on your project management method of choice (e.g. PRINCE2) and/or team size, but please enlighten me.

+1  A: 

Depends on what exactly you're putting in the JIRA. If it is dev items then that's usually the responsibility of the team/technical leads of each team. If it is done by anyone higher the granularity wont be good enough and the estimates will tend to be horribly optimistic

Quibblesome
A: 

At my job, general tasks that don't require a strong knowledge of your applications (i.e.: create a user that has certain permissions, create a report that aggregates certain data points, ...)can generally be created by the Project Manager then assigned to the team lead/senior developer. The team lead/senior dev then creates smaller tasks that are subsets of the more general items logged by the PM and assigns those to specific developers, taking into account their skill set (i.e.: the SQL guy can write the queries to get the data, the client UI guy can work on the front end of the report, ...). Having PMs or project owners directly assign detailed tasks to developers tends to create confusion and might jeopardize a release.

Zabbala
+1  A: 

In my company we usually do it like that: If the person who wrote the spec document knows the system for which he wrote the spec well i.e. he will be able to judge the best granularity of the ticktes/tasks,I'd ask him to create them. Otherwise, the project leader (who knows the system in and out) creates the tickets (which reference the relevant chapter(s) of the spec document).

As for assigning tickets to specific developers: this is normally done by the project leader (who should have the overview of who is how busy). We also have a "pool" where a developer can pick a ticket himself (but we use this mainly for bug fixing and not for new features, otherwise there a risk that you'll loose total control over what features are included in the version you're currently developing).

ISW
A: 

depends on alot of things... who wrote the spec? size of project, size of dev team, how strong are the developers design skills? who manages the developers time? etc.

typically its been a lead developer in my experience. whoever is leading the actual development of the project. i have seen the project manager be responseible for this as well but it never works as well due to thier lack of technical knowledge.

assuming a business person wrote the spec and you have junior/intermediate developers then a lead who manages those devs would write a series of small technical specs and assign those to developers.

mike
A: 

Yes, this is something that your software development method determines, unless it does not talk bout it; there is no right answer, and the better answer depends on your project and people.

The task that you are describing is the functional decomposition, where you take each requirement in the business analysts' requirements specification and break it up into the functionality that implements that requirement. This is also known as functional design, so you are talking about a functional designer.

You may choose to document your functional design directly in the description of the New Feature JIRA issues, as we sometimes do, or you may have an intermediate functional requirements specification. In the latter case, splitting up the functionality into developer tasks may be more straightforward (in the sense of not being a design activity) and might be done by the project manager or technical lead who assigns work to developers, or alternatively by developers who assign work to themselves.

In every case, this task is about translating from the business analyst's perspective to the developer's perspective. How you need to do this, and in how many steps, depends on how well the writer can put it in the developer's terms, and how well the developer can understand requirements written in the analyst's terms. Fewer steps cost less time and introduce less noise, but require people with better understanding and communication skills.

Peter Hilton
A: 

Ultimately, it is the PMs job to develop the WBS (work breakdown structure); which is effectively made up of the tickets and subtasks that you refer to. In reality, he/she may not be as close to the problem as the footsoldiers are; so it's probably going to be a collaborative exercise to find all the items in the WBS.

Who actually inputs them into your issue management system/bug tracker/project scheduler/project management software/FogBugz is literally whatever team member he/she directs to do the job.

CodeSlave