Real work and left work is in Activities/tasks. You should use tasks for Agile as well.
Link requirements to tasks and it will do the job because you will have linked the work and tests via requirements - all traceability will be in place

Hi,

I share Evgueni's opinion : work is on activities ...
Then requirements are linked to activities.

An activity can be a Scrum Sprint ...

What could ease real work input is to have work input like in Tickets.
Ticket #1209 recorded to think about it.

Hi all,

Indeed I think an Activity can be used for a Scrum sprint.
What I'm missing is:

1) link a requirement to this Activity: is it possible to do a "link to planning activity", like we have for Tickets ?
I do see the possibility of adding an activity as "linked element", but this link is not quite as rich...

2) as you say, real work input ,like we have for tickets. If we have a "strong" link to an activity, then we keep the idea that work is in Activities, but the input is more detailed because it is done on a per requirement basis.

Basically, this is the way of working that our Agile projects use, currently with standard commercial tools. I would like to have them switch to Project'OR, but in order to make it transparent to our clients, we need to show that we can still deliver the same level of information (for example, a global view of real/left work on the Activity/sprint, and also details of real work per requirement).

Evgueni,
do you work in Agile methodology with your projects ? I'd be interested to know how you've organised things... 🙂

Thanks for the inputs!

1. There is 'Linked Elements' - use it to link requirement to Activity
2. Requirements is not a scheduled work - they are requirements for the work! So, you need just to have workflow set the way you can control and VERIFY them through the testing when the work is completed. Tasks (Activities) are the implementation of requirements, so you need to monitor progress with implementation not with requirements!

Yes, we are using Agile methodology and i cannot see any problems so far - the progress you can easy show in planning. We even creating Tasks (Activities) with the requirement Id as the name sometimes, so you can use this approach to show progress in requirements implementation

Ok, thanks - it's good to know that you are able to use it in such an environment.

I will dig into this some more - and maybe come back with more questions later on !!

Thanks again 🙂

Hi caccia,

we use it in a very similar way - but it's a mixture of classic and agile approach.

Our requirements entered in Tickets with type = requirements. All approved requirements will be linked to an Activity. Every Activity has a target version - in our case we have two monthly releases (target versions). All efforts booked weekly on Activities.

Report: Current Status - Version Detail shows what will be delivered on what target version. If you enter target version in Activites and Requirements / Tickets, then you will see, what is delivered when.

I hope this supports your deep dive on this topic.

Regards,

Klaus

Hi Klaus,

Thanks for the info - I like your idea of using a ticket type = requirement, sounds like a good idea.
I haven't given the subject much more thought yet, but I'll keep your inputs in mind as well.

Thanks ! 🙂

There is requirements in projectorria already - what's the point to duplicate it?

Hi ekolossov,

we didn't duplicate. It's an simpler approach for us, to have all requests, tasks and issues in one - we use the Tickets for this purpose. Type differentiate with Ticket type between this types. To be honest, we have had this approach long time before Requirements have been invented.

Regards,

Klaus