Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update WaysofWork.md #57

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Update WaysofWork.md #57

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fe22e42
Update WaysofWork.md
Davsarper Jul 10, 2023
d633cae
Update WaysofWork.md
Davsarper Aug 7, 2023
6bf4a80
Update WaysofWork.md
Davsarper Nov 16, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions WaysofWork.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we consider this still necessary, or rather, is this something we would like to implement?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is only helpful if we plan to do some kinda analysis with it afterwards

- 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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to make this mandatory? there is interest on being able to analyse this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for capturing actual effort spent if that's possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to encourage/force this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, but also don't we get this for free when an issue is closed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, see discussion on 35 (effor estimates)

- Story Effort: leave blank, does not apply to base issues
- Team Accountable: who is the momentum generator for this task?
- Project/Funding: which project within DSH does this task belong to?
Expand Down Expand Up @@ -65,6 +68,8 @@ Stories should not be created without consensus, if you DO NEED to create one to

It is the responsibility of the Accountable team or person, with help from the RPM where necessary, to create and complete a story.

Active stories are expected to be updated at least once a month via a comment on their progress
JimMadge marked this conversation as resolved.
Show resolved Hide resolved

In the body of the issue:
- Specify the goal this story refers to
- Describe what the work is and what it will achieve
Expand Down Expand Up @@ -199,6 +204,7 @@ by default it is organised by team accountable and shows only the stories each i

Dragging and dropping a story in the calendar will automatically fill in or modify the planned start and end.

Creating a new issue from this view will automatically have its accountable team filled.

#### Roadmap - Tasks

Expand All @@ -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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


What statuses to use and how can evolve with use, the most important rule to follow is to respect the backlog as agreed upon work.

It is recommended task issues are updated weekly.

#### Workload

A table view filtered so workload can be analysed,
by default grouped by Accountable Team and filtered by planned stories.

It shows the sum of current FTE.

#### Table

How to best use it will be discussed and developed together, no direct or immediate use yet (do suggest!)
Expand Down