In-depth understanding of the concept behind plan items and execution items
Our company has started using RTC for planning not long ago, and we still are learning a lot.
The online help and documentation does not provide very much information about the conecpt of Plan Items and Execution Items (Work Item Type Categorization), therefore we have configured this distinction to the best of our knowledge.
- Some default values for excluding plan/exection items in different plan types - this can be changed, no problem
- Plan Items cannot be dragged in Taskboard Plan View (change state of work item), but in Kanban View.
- Execution Items must be linked as child items of Plan Items in order to appear in the same line in the Taskboard Plan View.
- Ready-to-Use report "Team Velocity" reads the Storypoints (Complexity attribute) just from Plan Items, although the Storypoint value has been set for Execution Items (in some of our teams).
- As some of our teams define the Complexity in Plan Items while others use the (linked) Execution Items, we have assigned the Complexity attribute to both work item types. I just found this answer by Ralph Schoon, indicating that there is a chance to sum up Complexity values automatically (https://jazz.net/forum/questions/151613/story-points-of-child-epicsstories-and-parent-epicstories). If we try to change our configuration to achieve this (remove the complexity attribute from the parent work item type), is this feature only limited to the parent/child-relationship? Or can I use another link type for achieving this?
- What else are the consequences for the decision which work item types shall be plan items and which ones shall be execution items? Is there anything more we are not (yet) aware of...?
Juergen
Accepted answer
Jürgen,
I tried to summarize some of the fundamentals here: https://jazz.net/wiki/bin/view/Deployment/RTCProcessFundamentals#Planning_Fundamentals
That is my understanding, not necessarily that of all.
I would like to approach this a bit different. If you are planning you will have goals, things you want to achieve on a higher level. Then there are things you have to do to achieve the goals.
Plan items are basically to express the higher level achievements, goals, features, stories whatever you call them. In planning you want to have an overview what the major contributions to the plan are. You often don't want to be distracted by all the details. Such a goal should be planned on a level that can be done in an iteration. You can use a breakdown e.g. Epic->Story->Story to break a huge plan item down into smaller pieces you can actually do in such an iteration.
(Agile) Effort estimation has the idea that humans are really good at estimating a rough ballpark number 1 point, 2 pint, 3 point, 5, 10, ... but for a lot of things they are bad at estimating 1 hour, two hours etc. The bigger the numbr the bigger the estimation error. Will this work take 100 hours or 120? So the idea is to have such a complexity at the plan level with fewer choics the higher the numbers to account for the fuzziness of estimating. You can use an enumeration or an integer. If you use an integer you should be aware of how bad humans are estimating at that high level for big numbers.
Execution items is the details what you have to do to get the plan items done. In the execution items you want to track the details. You want to be able to split the plan items in many tasks you have to do to finish them. Tasks should be small enough to be done by one person and ideally you should be able to estimate how long they take.
As far as I can tell, in RTC you flag the plan items in the planning configuration. All other item types are considered execution items. You can change the decision any time. There are some reasonable decisions already taken in the process templates.
Roll up using parent child only works within one project area.
On Plan item level the complexity is rolled up. If you have a very abstract level such as Epic, that item can be specified as top level item with no complexity on its own, so that the complexity of the child plan item (stories) is the collective complexity. Plan items usually don't have an estimate, corrected estimate etc.
Execution items don't have a complexity, they may have an estimate, corrected estimate, time spent,... The roll up (within a project area) allows to roll estimations and tracked time up to the plan item level.
There is cross project planning using tracks/contributes To links, where the link allows to track plan items in this plan to plan items in other project areas. Too much for here.
There is a bunch of stuff I don't know that I don't know. So I can't tell you if you are missing something. I would suggest to have some small systems with the JKA Banking/Money that matter example to play around with. It has some data to start with and some plans. There are also various articles in the library. I think I put some into the fundamentals article.
I personally think the differentiation in plan items and execution items is useful. It allows to filter out details or focus on details. I also like the complexity versus the real effort tracking (says one of the worst planners and estimators on the planet).
If you play around with this, be aware that adding attributes can not be really reversed. But RTC should give you some flexibility to change things back and forth.
Comments
And don't get overexcited about planning. The capabilities RTC has for planning are nice but it is no magic and somehow people always expect more than it can offer. Agile planning is ok.
I have seen a lot of people struggle with the traditional planning is not at a level. RTC is not MS Project and never will be.
Ralph, thank you very much for your fast and detailed answer!
To understand your explanation on rolling up (within work items of the same project area) correctly: This only works for parent/child relationships between work items, right?
We are not expecting miracles from RTCs planning, but we did not have a consistent process of agile planning (across our teams) in the past, therefore we are struggling to find a common process in RTC (with one project area for all our teams) now.
We are not using the attributes correctedEstimate and timeSpent now, and I don't know much about their benefits yet. If I understand you and RTC correctly, the proposed way of estimating would be:
- Plan Item: Complexity (Storypoints)
- Execution Items: Estimate (in hours) => will be summed up in parent Plan Item
- Execution Items: Corrected Estimate / Time Spent (in hours) => will be updated while working on this task
Then there are some other planning attributes I am not sure of how (or if) they relate to plan/execution items, like dueDate.
dueDate has some relationship with the iteration (via the Planned For-attribute of this work item), but is it thought to be used just for Exeuction Items or also for Plan Items?
Same for startDate.
There are some standard attributes (taken from the SCRUM template) that we had not been using in our past system, therefore we don't see the use of these attributes yet and we're currently trying to discover and learn the features that are being implemented behind these attributes.
Roll up only works for the parent/child relationship and only within one project area.
The Planning component only knows how many hours are left until the end of the iteration and how many hours the project members are planned to contribute. Time spent can/will not be automatically updated by RTC. The user has to do that.
Estimate, Corrected estimate, Time spent/Time remaining are the main source of information that feed the progress bars (https://jazz.net/library/article/586). I like time spent for my work, more agile shops prefer time remaining. Planning calculates the times across these three attributes. If corrected estimate is set, the initial estimate is frozen.
Due Date only provides with a warning in a plan view. Start date is set when the work item is set to start working, if I remember correctly. I can't say I have experience with those two attributes. Due date is one where customers often expect more. There is not much automation around it. Custom automation can be created (e.g. due date noitification).
One other answer
Jürgen,
I have supported many clients in terms of deployments for RTC planning;
Traditional (FPM) and Agile...
Starting simple with the FPM (formal Project Management) using work item and getting the understanding of how the plan works takes time. Start Simple and review the Iterations and goals your project wants to achieve.
The My Stuff (user option) and new "Quick Planner" give users a great view of their tasks and work allocations.
It takes time to understand planning (8 years for me) that if your users are split across teams and projects then this complicates planning; as % allocations are split by the system individuals can change allocations.. Tasks take longer if their allocation are split. Microsoft Project let's you over allocate etc. but RTC is not as flexible.
I prefer to start simple and then add some additional functions with Dashboards / Plan views etc. the biggest benefits are the collaborative Task working; Links and approvals and reviews to help the project meet it's requirements and to keep track of "RAID" or other key elements. The plan is then just the best way to view the complete picture. Making plan views and adding filters, colours and other columns supports teams and users - so lots of good tips there.
I also prefer the simplicity of Agile within the RTC Template; and this meets with agile/scrum principles .. and drops a lot of the complexity of the Traditional planner.
Also many of the reports are more towards the Agile or Scaled Agile (SAFE) Templates.
Good Luck