Answered Handling releases in the best way?

Hi! I know ClubHouse is really flexible and that one can use it in different ways. I’m thinking about using ClubHouse for a product where I need to connect stories to releases.

Let’s say Release 1.0 has 10 stories, Release 1.1 has 3 bug fixes etc. How would one model this? I can see some solutions, but I don’t no which one to go with...

* Milestone = Release

* Epic = Release

* Iteration = Release

 

Anyone else using ClubHouse like this? How do you “tag” items in a release like this?

Didn't find what you were looking for?

New post
Would you like to add your +1 to this post?
1 out of 1 found this helpful

Comments

4 comments

  • Comment actions Permalink

    Hi Markus!

     

    You are correct in that there is no "wrong" way to use Clubhouse, though there are some best practices. That is to say, you could use any of those dimentions, but from what we've seen, it's best practice to use Milestones.

     

    Because Milestones are designed to move through a simple workflow and become completed, they probably won’t work well for long-running “themes”, unless they’re broken up by quarters or halves. As such, they are best suited for time-defined boxes in a year to denote when significant amount work (such as a release) is planned to be completed. So it could look like this:

     

    Release 1.0 Codename 'Markus' - Q2 of 2020

     

        Contains 3 Epics: One for UI work, another for BE work, another for Marketing.

     

    Since Epics are collections of stories, these will of course have several projects from different teams all working towards the release. At the lower levels they'd only focus on completing work that impacts the Epic. Ideally these Epics should have due dates, to keep work on track. As work gets completed at the Epic level, this will of course impact the Milestone completion. This was an example, of course; how many Epics are within a Milestone to complete the release is entirely up to you.

     

    0
  • Comment actions Permalink

    Hi Eury! 

    Thank you very much for your help!

    I've looked at Milestones for this, it makes sense and I can see that this would be a very good solution if the product is created by multiple teams, potentially with multiple different workflows. In my case we're only two persons working in the same team/workflow. When I tried this approach it felt like the Milestone did not provide the level of details that I'm looking for, my "end goal" is to get a really simple overview of what was included in one release, given this a Epic seems like a good entity to keep the release. But it might be the case that I'm making my Epics to big? In my current setup I have like 20 stories with totally different kind of work within. 

    Do you think that I should make my Epics smaller and use Milestones our would it, given my setup, be suitable to use an Epic for a release to get a really simple overview of what was included in this release?

    And also, how does "iterations" fit in to all of this?

    0
  • Comment actions Permalink

    Hi Markus,

    i had the same issue, I'm using Labels right now to tag Releases.

    I create a Label with the release name. (ie v1.0.0) and associate it to all the stories (and epics) that are part of the release.

    You can also create a Space with the Label as a filter, to have a quick glance of the progress, and in the Label detail you also get some analytics on the Label progress (like Burndown Chart).

    I use Epics to map features which are cross Project or that are composed of multiple Stories, while Milestone are used to aggregate longer-term efforts.

    0
  • Comment actions Permalink

    Sorry to bump an old thread...

    We've been using Clubhouse for over a year. We release a SaaS product every 4-6 weeks. I feel like our system is working pretty well:

     

    Milestones represent the monthly release plan. Epics describe the high-level features that are going into the plan. There is a high-level catch-all epic for things that fall outside major features or are product bugs from prior epics. The epic contains a description and mock-up of the feature. The epic has the stories required to complete the feature. We use tasks to break down the stories as required.

     

    We've integrated the Clubhouse API into our application so that users can suggest features or report bugs and they get put directly into User Suggestions or User-reported Issues epics. These epics aren't in a milestone. We pull stories out of those epics and put them into the appropriate Milestone/Epic when they will be worked on.

     

    We use labels primarily to identify user reported stories or identify themes, or to set severity/priority of bugs (since Clubhouse doesn't have a concept of severity/priority).

     

    One other thought... We don't use iterations. We don't do sprints. Rather we have cutoffs for monthly releases and if epics are complete and ready to go, then they are included in the release. Otherwise they are pushed back to the next month. So it's not unusual for us to reorganize our Milestones overtime by moving epics forward or back.

    0

Please sign in to leave a comment.