Blog Post Actions
Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 559 views
  • Likes 5 likes
  • Comments 4 comments
Related
Recommended

Sound and Vibration Measurement: Road Test time management with GitHub Project Beta

Jan Cumps
Sound and Vibration Measurement: Road Test time management with GitHub Project Beta

I have a decent set of objectives for the Sound and Vibration Measurement Hat for Raspberry Pi road test. To keep focus and track, I'm using GitHub's new Projects Beta. The new Project app is simple - simpler than the previous incarnation. And I'm trying to keep it like that. I only intend to use it to track my goals.

In this post, clickable headers will open my actual project view in a new browser tab.

Work items

I entered all goals in a table. For granularity and effort, I used agile User Story sized objectives.

In the project settings, I activated a workflow that sets the status of each new entry to Todo.

Iterations

I've divided the available time into a 6 iterations. The first one 2 weeks long because that wasn't expected to go smooth. I was dependent on getting the road test kit, and had to set up the tool chain and development environment. The other iterations are all one week.

Backlog

I then made a new table view for the backlog - based on the same goals. The backlog is used to refine objectives and to assign them to one of the iterations. As filter for the backlog, I select all objectives that aren't done and not assigned to the current iteration. In a bigger project, I'd also make a view for the objectives assigned to the next iteration, because those are the ones I should refine.

Active Iteration

For this view, I use a board instead of a table. Because that's the one used to track progress of the activities in an iteration. It's one that should be easy to track progress, and a board allows to do that by dragging items to the next status. It also gives a clear overview of how I'm doing. It automatically filters all objectives assigned to this iteration.

No view for late work? No - although this can be made. If something isn't done, it should go to the backlog for replanning.

If you are interested to follow along, here is the public link: https://github.com/users/jancumps/projects/3/views/1

Link to all posts.

Anonymous

  • I finished the road test. Let's see how I did with project management.

    Timeline: I divided the road test into 6 iterations. The first one two weeks. All the other ones one week.
    My plan was pessimistic. I needed 4 of the 6 iterations to complete the goals and the hurdles along the way.

    This week's goals:

    Next week's goals - all done, I progressed faster than expected

    The backlog. These are items that aren't in the current iteration, and not completed:

    At the end of this road test, I only have topics left that I didn't plan. They were stretch.

    last: achievements and overview

  • in reply to shabaz

    yes. This may be a good example to showcase the practice. A short project.
    It's a bit of a theoretical showcase, because I'm a one man show. And that doesn't show the full impact of running an agile exercise.
    But as an exercise, it's good enough to get a grasp of the concept of cadence, iteration, increment and repetition.
    And to not have activities in the past  even if they are late. You can never manage the past.

  • Nice!
    Probably worth just mentioning (not everyone may realize) that this technique is how many software projects are done these days.
    It's quite different from older methods (e.g. managers stretched Gantt charts into ways they were non-ideal for, and relied on traditional longer development bundles rather than smaller tasks, or developers were left isolated on their own to break down their larger objectives into things they needed to do, and no-one checked if it was optimal/efficient : ).