Update WaysofWork.md #57
Conversation
Added FTE field for task issues, added Actual dates as required for closing, added Workload in project views
| @@ -32,7 +32,10 @@ When created in another repository try to still apply these rules as much as pos | |||
| - Backlog: if it has been agreed as necessary work | |||
| - Planned: agreed and we know when to address it or by when it needs done | |||
| - Points (effort): assign a value effort from 2 to 9. A value of 1 typically means that the task is so short it would be better merged with another, a 10 means that it is probably best split in more than one issue (maybe it needs to be a story instead of an issue); if you really want to assign a 1 or 10 (cannot be merged or split) do so | |||
There was a problem hiding this comment.
Do we consider this still necessary, or rather, is this something we would like to implement?
There was a problem hiding this comment.
I think this is only helpful if we plan to do some kinda analysis with it afterwards
| @@ -32,7 +32,10 @@ When created in another repository try to still apply these rules as much as pos | |||
| - Backlog: if it has been agreed as necessary work | |||
| - Planned: agreed and we know when to address it or by when it needs done | |||
| - Points (effort): assign a value effort from 2 to 9. A value of 1 typically means that the task is so short it would be better merged with another, a 10 means that it is probably best split in more than one issue (maybe it needs to be a story instead of an issue); if you really want to assign a 1 or 10 (cannot be merged or split) do so | |||
| - FTE: estimate % of person time while ongoing this issue will take, for example 2 people dedicating 1 day a week, wiht an issue duration of a month would be about 0.26. | |||
| - Important! Update this when closing | |||
There was a problem hiding this comment.
Do we want to make this mandatory? there is interest on being able to analyse this
There was a problem hiding this comment.
I'm not sure we want to do that at all.
If we change it after closing the issue we have lost our estimate. I don't think we will measure actual FTE anyway.
There was a problem hiding this comment.
This is true, also ties with
38 - Add actual dates when closing
Let's only update/fill start date when actually starting (if issue was planned in advance). Date difference will give us what we need to analyse along with knowing who worked on them.
Effort: we are not realistically going to use FTE AND Points, so let's keep one or the other:
- FTE: we are more familiar with it and use it elsewhere BUT I dislike the pretense of actually knowing with proper detail what the task will take
- Points: are quick and provide a sense of the level of work, the resulting escale is well adjusted to the team after a time BUT is new, requires being persistant and consistent; It can be a bit of a fuss
While I prefer points I acknowledge FTE may work better for the team
There was a problem hiding this comment.
That sounds good. I think looking at expected/actual start/end dates could be useful. Although, we might just learn that things take longer than we expect 🤷.
Still, if we want to capture that we can and we shouldn't overwrite the estimates.
There was a problem hiding this comment.
+1 for capturing actual effort spent if that's possible.
There was a problem hiding this comment.
I prefer estimating using FTE. I know it isn't accurate, but having the unit makes it clear what 1.0 FTE means. It is the same for everyone. I'm not sure how 2 of my points compare to 5 of yours.
It makes it easier to compare across people/projects and gives a better impression of how reasonable the time investment is, even if it is a rough estimate. @jemrobinson thoughts?
There was a problem hiding this comment.
@jemrobinson would you capture actual effort at a task or story level? there are two main ways I see of capturing it:
- Add a field for actual effort (instead of overwrite) and ask for it to be filled in when closing
- Ask for a closing comment with the effort and final outcomes, something of a mini report on closure. If this does not sit well with issues closed in other repositories, it could also be an update in the story "closed related issue ##, final effort X, outcome Y"
- The above but reporting in the weekly meeting/note
Any other suggestions?
There was a problem hiding this comment.
@JimMadge ok to using FTE, points do work and in the end the whole team comes to understand them but it requires time and probably following SCRUM more closely than we are doing. We are experimenting enough already
There was a problem hiding this comment.
Again think this is cool IF we're going to (and see a benefit from) analysing it
| - Add planned dates when known | ||
| - Add actual dates when closing |
There was a problem hiding this comment.
Do we want to encourage/force this?
There was a problem hiding this comment.
I think so, but also don't we get this for free when an issue is closed?
There was a problem hiding this comment.
true, see discussion on 35 (effor estimates)
| @@ -211,9 +217,19 @@ It allows to quickly view the total effort (as a sum of points) that each team h | |||
|
|
|||
| Likely to be the most day to day view, it shows issues by status. | |||
| For simplicity only one view exists, where task level issues and stories cause confusion use the Story label to filter. | |||
| By default it is filtered to show only tasks. | |||
There was a problem hiding this comment.
What should be the role of the board in our day to day? Should it be used during the weekly? It could be a good way of centralising our activity
There was a problem hiding this comment.
I think it should be useful in the weekly and also daily as a regular tool for work.
If it isn't, then that is probably a problem.
There was a problem hiding this comment.
Issues need to be added to the project, which isnt happening. I have stressed the need in the issues section, also simplified fields so this can be done without much more work
There was a problem hiding this comment.
Yes, I'm definitely guilty of that.
I think some of the tension might be. Do I really have to add every issue to the project board. Do I have to create an issue for everything I do that doesn't already have one?
It feels a bit like busywork where I'm not entirely sure what the benefit is. Especially if we report out "What we've been working on" to get an impression of what people are doing.
@jemrobinson @craddm @edwardchalstrey1 @harisood thoughts?
There was a problem hiding this comment.
Here is where I am split, honestly for me as RPM if you report out weekly I have most of what I need. I am still left without a way to assess actual workload (unless we complicate the weekly template) but probably not the end of the world. But thought it would help us work better together and collaborate if we see what we are up to in a more dynamic, yet async, way. Think on what you want to use it for.
Also it is the best way to check that whatever we are working on contributes to the agreed priorities. If it doesn't match any, are we spending our time in what we said we wanted to spend it on?
So I would probably say yes to adding all issues if as a team we want to use the board, this can be progressive as you are about to update or create one just add the project.
Another solution for tasks that are not quite issues could be to only add them to stories, or to say in the weekly updated "contributed to story xx by doing yy" - Maybe if there is a check between work and goals that is enough where you think an issue would not be appropiate.
There was a problem hiding this comment.
I am still left without a way to assess actual workload (unless we complicate the weekly template) but probably not the end of the world.
What does actual workload mean here? What do we get if we can quantify it?
Another solution for tasks that are not quite issues could be to only add them to stories, or to say in the weekly updated "contributed to story xx by doing yy"
I think this is what I prefer. I strong want to avoid having to do both.
I think the advantage here is it is easy to see snapshot of "What happened this week". Which isn't so easy with a big list of issues (possibly split between different repos, boards, milestones).
Some areas where I can see issues being awkward are,
- Work that isn't conducted on GitHub
- Workshops
- Community groups
- Ad-hoc support
- Project management/finance stuff
- Work on external repos
- Work on repos not so strictly tied to DSH
There was a problem hiding this comment.
Also it is the best way to check that whatever we are working on contributes to the agreed priorities
In a very strict and efficient world this is how things ideally would work (so we can be sure that we're always working on things that are moving us forward as a project). For me having the roadmap open and tagging each relevant issue when I open a new one isn't too big a deal, and probs good for accountability, but I also haven't been doing it properly yet so not sure how much I would live this in practice.
I think for team accountability it's good to be able to justify how your work fits into the wider teams goals by some method. If not this I'm not sure what else
| @@ -32,7 +32,10 @@ When created in another repository try to still apply these rules as much as pos | |||
| - Backlog: if it has been agreed as necessary work | |||
| - Planned: agreed and we know when to address it or by when it needs done | |||
| - Points (effort): assign a value effort from 2 to 9. A value of 1 typically means that the task is so short it would be better merged with another, a 10 means that it is probably best split in more than one issue (maybe it needs to be a story instead of an issue); if you really want to assign a 1 or 10 (cannot be merged or split) do so | |||
| - FTE: estimate % of person time while ongoing this issue will take, for example 2 people dedicating 1 day a week, wiht an issue duration of a month would be about 0.26. | |||
| - Important! Update this when closing | |||
There was a problem hiding this comment.
I'm not sure we want to do that at all.
If we change it after closing the issue we have lost our estimate. I don't think we will measure actual FTE anyway.
| - Add planned dates when known | ||
| - Add actual dates when closing |
There was a problem hiding this comment.
I think so, but also don't we get this for free when an issue is closed?
| @@ -211,9 +217,19 @@ It allows to quickly view the total effort (as a sum of points) that each team h | |||
|
|
|||
| Likely to be the most day to day view, it shows issues by status. | |||
| For simplicity only one view exists, where task level issues and stories cause confusion use the Story label to filter. | |||
| By default it is filtered to show only tasks. | |||
There was a problem hiding this comment.
I think it should be useful in the weekly and also daily as a regular tool for work.
If it isn't, then that is probably a problem.
added some updates to issue and stories, for discussion
Added furhter context to meetings and time together
Added FTE field for task issues, added Actual dates as required for closing, added Workload in project views.
Please do use this PR to also discuss and propose changes about other aspects of this document.
The requirement to fill in actual dates follows an ask during the Monthly meeting and interest expressed before in analysing the planned vs actual deviation.
Adding FTE field to task issues to estimate and record task effort responds to the ask to track actual dedication, it is to a point overlapping with Points; do we want to keep both fields? Is there an interest to develop a point system or will everyone have an easier time using FTEs?
Once this PR is finally approved, issue templates will have to be updated.