add agile specific project templates

Yes, its something that should be handled eventually - as that seems to be a lot of where project management is going now.

However, it may be lower priority for now as we get the Project Management Module fully working "as is" for Drupal 7.

We can always start discussing what this would mean, though and where it would fit in.

Could you elaborate on where you'd see each of those fitting in to the Project Management Module?

Isn't this something on the lines of what this post in Groups tries to talk about?

I suggest we start talking about which features may be appropriate before spending too much time on code.

Don't mind whether the conversation happens here or at Drupal Groups.

Adding Calendar functionality seems to be a logical next step after Date functionality is added. (see Roadmap for D7 port )

I agree that an element of milestone or sprint would be useful in Project Management.

The thing I wonder, though, is whether we could support agile without the user having to select upfront whether the project is agile or waterfall.

What i'm thinking is that most of this functionality is agnostic of the progress. Thing like tasks could have a choice between setting a start / end datetime, or just a duration. Any list of tasks could have drag'n'drop functionality for weight. It might help.

All my thinking at the moment has been quite conceptual, by the way, I haven't thought too much about practicalities.

I agree that it would be good to move to Field API before making changes such as this - it'd also open up a whole realm of possibilities given the features of each field.

Another thing that I'd like to sound out opinions on (which I think is related to this issue), is a proposal to merge the "Task" and "Ticket" content types.

If you look carefully at the "add Task" page, you'll notice that it already has a lot of the fields that we're talking about: duration, weight...

(http://drupal-7.project-management-module.org/node/add/pmtask - I'm afraid you'll need an account to view that page.)

The "add Ticket" page (http://drupal-7.project-management-module.org/node/add/pmticket) has almost all of these (doesn't have weight or step number).

Then look at other project management systems, and you'll see equivalent objects masquerading under a load of different names:
- Stories
- Tasks
- Tickets
- Issue
- Case
- ...

Whilst I appreciate the differences between them, by typecasting as one or more of these, we pigeonhole Project Management into a particular use case.

We could instead focus on building a flexible content type that has the functionality of these similar things, and include a "Type" selector if necessary that could allow some selection (similar to the "Category" dropdown on this issue on drupal.org).

Then, whether you're building a Gantt, a backlog, priority list, etc... it could all be done by filtering a single view (formatting different ways).

Of course the advantage of using Fields API is that site builders can then easily use a module such as Field Permissions to restrict which fields a customer could have access to view or fill in.

Another thing that I'd like to sound out opinions on (which I think is related to this issue), is a proposal to merge the "Task" and "Ticket" content types.

I disagree with this if you are talking about merging Task and Ticket into one for all use cases. A call to a Help Desk is different than building an Airplane. Large complex projects have efficiently been managed using WBSs for a long time. A WBS (work breakdown structures) can now be handled well using Storm/PM structure. The Task is a way of defining outcomes (I like to think of them as deliverables) while Ticket is a nice way to define/track the actions required to complete the Task. Timetracking then details the person's hours spent primarily on the actionable Tickets. When all Tickets are complete that deliverable is ready. When are deliverables are complete the Project is done.

Perhaps but now I think the way it works is that the ticket module "Allows creation of tickets for Projects and Tasks". Are you suggesting that tickets should also allow for creation of tickets directly for Organizations? (Here maybe you don't even enable the Project and Task modules.)

If the PMticket (sub)module allowed for creation of tickets for organizations, then admin would not have to enable PM project and/or task (sub) modules. This may fit a use case for single consultant working for a few different organizations

tickets are for clients

Just trying to understand a use case to match this statement.

Related reading: #364252: What's the difference between a task and a ticket?

**What a PM User thinks**

Ticket and Tasks remains a different entity cause,
1. Need to handle permission differently.
2. Need to populate various attributes used differently.

================================================================================

**How a PM Developer Thinks.**

Reason why Task and Ticket appears same from a programmers point of view. 
There are so many common variables and behaviours ( functions that implements 
it), that defines them that, it looks as if both are same and only differs in 
name.
1. Both can have priorities.
2. Both can/need to be tracked using timetracking.
3. Both has to be assigned to somebody responsible.
4. Both has status that reflects its progress.

================================================================================

**Solution 1.**

Ideally we should have a base entity definition that could be extended via GUI 
to create various types like Task, Ticket, Bugs, Issues, Task-Type A(gile),
Task-Type-B, and what not.

The configuaration options in gui should cover type specific,
1. Permissions,
2. Attributes,
3. Optional fields that can be turned on or off 
4. String overrides
   (add link text, type name, etc which are not covered by attributes).
5. How time and time tracking is handled.

By default PM could have two Types - Task and Ticket. 
Maybe we write a tutorial on how to disable current type and create a new type
of say Task-Type Agile.

This would be a MAJOR change. But think of how drupal's default installation
profile creates two node types Article and Page. Its doeble and clear and would
be awesome.

--------------------------------------------------------------------------------

**Solution 2**

A DuctTape fix. ( DuctTape can be used to fix your plumbing problem, but would
you?)

**Assumptions**
  We have one common content-type called Task which has a hidden checkbox 
  [] is_ticket. ( off by default).

  A task and a ticket is same entity with name derived from the context that it 
  is in.
  Context dictates if an entity is of Type TASK or a TICKET.
**I.a. Creation Context**
( read => as "the Task becomes a")
Normally,

1.  Client Creates a its  => Ticket
    (coud be a bug/issue/comment/suggestion/support request/angry mail/complaint 
    in real world.)
2.  Project Manager creates it => Task
3.  Tester creates it => Ticket 
    ( bug reports are tickets)
4.  Developer creates it => Ticket/Task 
    ( like filing a bug or creating a sub task).

There could be a scenario where PM wants to raise a ticket so that he could have 
the ac fixed in his cabin ( very important for business meetings you know :| ).

**I.b. Dynamic Context**

  Task and Ticket could transform into each other. A ticket can go on to become 
  a task. For example in a scenario, as long as ticket is not assigned to 
  somebody it remains a ticket. And once its assigned it becomes a task.

  This is quite tricky. here the context is dynamic and depends upon factor
  which are not known on creation time.

  Since Scenario I.a and Scenario I.b are not necessarily a rigid. Depending on 
  the institution using it, a context like bug could be defined as a Task or a 
  Ticket.

Possible solution.

1.  We can just expose this flag in node creation form. To make it more fancy 
    maybe make Task/Ticket creation a multistep process.
    ( skipping it if the user has access to creating just either one of them).

2.  We can maybe just retain the Creation context as discussed in I.a. and 
    spawn off another type. For example in a scenario where a Ticket becomes a 
    Task, we retain the original Ticket and create a new Task which is the child
    of the Ticket. There could also be scenario where the existing ticket can be
    resolved using a Task already in progress. This would mean we could have 
    Many ( Ticket ) to one (Task) relations too. ( This will ripple down and 
    affect how timetracking is reported).
 

3.  We can implement Rules action to set or reset is_ticket flag. 
    Provide few rules example on how to make intelligent decision on creating a
    ticket or task.

  All in all this solution relies on knowledge of workflow. Implementing this
would also result in trying to IMPOSE PM workflow on to the organization.

================================================================================

Conclusion:
  The ducttape fix usually spawns off many unthinkable issues which would later
  become a nightmare to handle. Given the number of people maintaining PM it
  looks like a disastor in waiting if we go that path. Since Task and Tickets
  are the most active area of PM, having a rocksolid stable Task/Tickets is a
  must. It may mean we would have to cut down features and keeping it simple.
  

PS. i used the code style so that it preserves the formatting i had used when writing this in my notepad++.

If we define Tickets as if,

Resources as in developers don't work on Tickets.
In case a developer assistance is required a task is created to handle it.
Tickets are assigned to supports.
Tickets unlike Tasks doesn't have a tangible output ( like a commit ).
A numerous number of ticket can be solved by just one task.
Tickets are analysed by a Support person and decides whether it should spawn off a task for the dev team or report it as a bug ( a bug lies on the boundary of a ticket and a task).
Time tracking is interpreted differently for a ticket and a task. A support might work on multiple tickets at a time. The microtime spend on ticket ( like chatting/responding/emails) is not needed to be recorded. For ticket the time counter starts the moment it is created. ( whereas a task can be created to be started at a later time ).

so coming back to "tickets are for clients" statement.

Reading the above definition of ticket, doesn't it make sense that it should be used by clients as against a Task.

The way to handle "support tickets" now using Storm is by

1. Setup a task or sub-task (by project manager) for an organization/project titled something like "Ongoing Support" (in the body field we often list the types of support offered both over the phone, emails, on-line etc). (working off a $$ retainer is a good way to handle this)

2. Create ticket (by the client or provider) against this Task,

3. Create Timetrackings ( the provider) to document the progress toward completing the ticket item.

Answering questions is a great way to support the customer. Having a methodical way to organize and track the issues enhances that support.

Administrative assistant type of support can take a call, log the ticket and even help resolve some issues (complete time tracking).

I agree that tasks are performed by a much more diverse pool of human resources than developers alone.

reply for #24.

Create a Project.
Client creates a ticket.
Support tries to resolve it, if unable to do so raises the priority
At some priority level it reaches the developer for consultation (call it a lvl 3 support), and once he/she agrees its a dev's job. The support passes the ticket to the developer's Project manager.
PM creates a task and assign it to dev.
Depending on the status of Task ( that which the support subscribes) , the Ticket is resolved if task is completed or kept pending.
A Ticket can even be closed with no task created.

-----------------

A note about client creating a ticket. This could also be that Support/automaton creates a ticket on behalf of client after an email is received or a webform is filled.

Sorry if I sound like a broken record here but...

A client will be creating a ticket based on the agreed terms of support - call it what you want "Baby-Sitting", "Hand-Holding", etc., but something like "Ongoing Support" may help towards maintaining good client relationships. I'd suggest the workflow of #25 be rejected by the project manager in favor of something like

1. Create a Project.
2. PM sets up a task for Ongoing Support
3. Client creates a ticket.
4. Support tries to resolve it, if unable to do so raises the priority
5. At some priority level it reaches the developer for consultation (call it a lvl 3 support), and once he/she agrees its a dev's job. The support passes the ticket to the developer's Project manager.
6. PM creates a Task or SubTasktask and assign it to dev.
7. If large project - Devs creates Tickets to complete Tasks and completes time track daily to record time and effort for this Ticket
8. If small project - Devs creates/completes time track daily to record time and effort for this Task
9. Depending on the status of Task ( that which the support subscribes) , the Ticket is resolved if task is completed or kept pending.
10. A Ticket can even be closed with no task created.

Storm/PM was designed to establish and work thru WBS (work breakdown structures) for project management. Fundamental to this of course is defining the Project and then the Tasks required to complete the project. Ongoing support for a "completed" projects can easily fit into this structure.

There are any number of other Drupal modules (http://groups.drupal.org/node/17948) for ticketing / help desk type of support that can be useful. IMHO - What sets Storm/PM apart from them is its WBS focus

A Project Manager needs to focus on managing billable time so he doesn't blow the project budget

A salaried employee offering product support doesn't really fall under that constraint. Hopefully though the support person still recognizes that "free" support to everyone is not sustainable, thus the need to bring in new work (Projects or Tasks).

I believe this is a permissions/access item that will be covered in planned upgrades. We can test for this condition when we get to that stage.

@dbt102 reply ofr comment #27

Regarding point #2: PM sets up a task for Ongoing Support

This "task" need not be a pmTask as such (there is no harm if it is so either). Projects having a Ticketing system in place is more of a "property" of the projects than a pmtask.

The pmtask are more like an activity that needs to be accomplished within a defined period of time or by a deadline. This assumption is very important. Especially in reporting, where for a project to be 100% completed, we cannot have a task which is essentially never completed (or until date defined in Terms of services).

Regarding points #7 and #8

It would be easier to take a decision, whether a person should work on a ticket or a task if you read the below,

A person working on tickets is not billed for hours spend on tickets. But his performance is measured on how many tickets where "taken care of" in an accumulated time frame. For example 10 tickets where taken care of in a month. 130 tickets where taken care of in a year.

"Taken care of" could mean, the tickets where resolved or they where handed over to dev team through PM. Time tracking on tickets means for how long the ticket was open ( as against in a task which deals with how long a resource was working on it).

This time doesn't add/subtract to the value of the project, cause anything that is billable on ticket should have a pmTask associated with it. But the time is important to track the quality of support, which in turn measures the customer satisfaction level.

Usually the people claiming for support are accessing it as a free service, or have already paid a fixed amount for it.

Its just a guideline and a personal opinion.

Am sure we can end up trying to solve a situation where nothing fits and its too complex.

but ain't we sidetracking from the original issue.

My comment in #1992264-21: add agile specific project templates was related to the original issue. Seems like it was long enough not to get any feedbacks :D

As At #364252-5: What's the difference between a task and a ticket? Roberto - original Storm developer - states it well

"I use tasks to register and schedule only deliverables, not to schedule every single piece of activity.
I use tickets to register requests by the customers and to plan the steps necessary to complete a task.
You can see tickets as your todo list, whilst tasks are the components of your project."

I've gone thru and tested several workflows relevant to discussion above and found some errors. I created issues #1996886: Error viewing Project and #1996896: Error Assigning Ticket directly to Organization to report them.

In #1992264-21: add agile specific project templates the two solutions seem to presume a fundamental flaw in the present Task/Ticket structure. I do not see it this way. I'm all for getting PM to a stable release, fully implementing D7 core functionality (especially Fields), and utilizing other modules (such as Date) and extending features to reports, charts, etc but I don't think any major change to accommodate Agile is needed. Seems to me PM supports Agile workflows now.

Cross reference #607712: Sprints and Backlogs (keeping both issues currently as both have good discussion and screenshots).

Related ticket at https://www.drupal.org/node/713182