Team - Multiple Branches Management Strategy | Flexibility | Productivity

Oops…! It's an era of Agile-Scrum-Sprint.

This is still okay but What about Monthly Releases and delivering various features using Jenkins as continuous integration (CI) tool?

Nowadays single team is working on different modules and various stories around them.

Working as a Technical Leader/Development Manager one may face difficulties in delivering various features in the same release.

This may be due to below considerable points:

• All features and issues are getting fixed on a single branch.
• Late identification of Technical Feasibility.
• Third Party dependency (UI/UX/Core Team).
• DEV/QA Team runtime bandwidth.
• Last moment urgent Production Bugs.

As a general practice and to avoid branch management, traditional teams have only one branch per release.

Changes done in that branch are targeting:

• New Feature/Story
• Bug Fixes
• Performance Fixes.

If any of the story/performance fixes can cause a delay that will lead to impacting timelines for other stories.

• This has to consider the overall effort to put in the last moment to roll back those changes.
• Again this leads to compromising the quality of the deliverable.
• Dev team gets less time to analyze the impact-areas.
• QA Team will get less time to verify the changes done.
• Marginally less/no time for regression.
• *Most importantly Handling pressure from upper management and criticism.

Below diagram gives pictorial representation of Teams' changes in Single Branch:

Let's try to analyze the scenario – Time for WH Questions!

·         What Team is doing?

o   Creating a Single branch from the Production/Stable branch for a release.

o   Making changes for Bug fixes, Performance issue fixes, and Story Development in a Single Branch.

·         Why Team is doing changes in the Single Branch?

o   Avoid extra branch management.

o   Availability of QA Environments.

o   Avoid Migration/Regression efforts on every branch.

·         How is it impacting?

o   Anything gets delayed entire feature suit is getting delayed for a release.

o   Timelines are getting missed.

o   Last moment extra efforts without deeper analysis.

o   Compromising Quality of deliverables due to lesser Testing Time.

It's time to change the way changes are getting pushed in Single Branch and come up with multiple branching strategies.

Let's summarize what needs to be achieved & HOW?

•  Need to have Feature-Shelf so that based on decision any time any Merge-Ready Feature can be released in production with good quality.
• Want to have no pressure from management for technical items.

·       No impact of any Story development/release plan decision on other Story.

o   How? à Separate Branch for each Story and Performance Fixes.

·         Every Story branch should have the latest issues fixed in this release.

o   How? à Separate Branch for Bug Fixes name it : team_fixes.

§  Create Story Branch from team_fixes branch and keep merging on regular basis.

·         Where to push a fix for Story Defects?

o   Every fix for Story Defect must be pushed in the respective team_story_x branch only.

·         Single Environment for QA to validate all these changes.

o   How? à Create team_story branch where all story (team_fixes, team_story_1…. team_story_N) and performance(team_perf) branches are merged on daily basis if those are stable. J

o   Migration and Regression will be done on single environment. (Same Target as using Single Branch Previously)

·         Jenkins/CI:

o   Run Compile & Test Execution job on individual branch.

o   If Selenium tests written have single Job for team_story branch.

Please refer below diagram for suggested Branching Strategy.

Please feel free to comment to this article for any suggestion and queries.

Team - On Track Concept Using JIRA and Confluence

If you are using JIRA and used its Search Feature to look for particular issue or list of issues, it's very cumbersome to do that every time.

One may find lots of Drop-downs for various fields for creating JIRA Filter Criteria using BASIC Query.

To do advance querying, one may require Knowledge about JQL – JIRA Query Language and fields used in JIRA.

Considering overall efforts to look-up and get stats every time one can store such queries as a JIRA Filter.

For a Scrum Master or Development Manager keeping track of various Features, Story-defects and Product issues is not an easy task for every day.

One have to think, Dev Manager generally takes care of multiple modules and different teams.

To do this task more productively, we can use Confluence along with JIRA to have customize Dashboard.

This article will help to know more about what your daily-dynamic Dashboard should have and how to prepare the one using Confluence-JIRA-Filters.

As I have pure technical background and love to follow coding principles, I am trying to avoid repeating the items each time and each place.

Before we dive into knowing what are the things to be done for Tracking the Team Stats, we should be knowing which items we should look for.

On day-to-day basis, every team generally works on Sprint tasks, so it may be Stories, Story Defects, Bugs, Testing or Miscellaneous Items.

All these things can be tracked in JIRA against different issue types by creating tasks and sub-tasks for EPIC, Story, Story Defect, Bug, Sub-Tasks, etc.

There is a good article about Agile-Sprint Planning, refer this link:requirements-epic-feature-user-story-task-size-and-estimation-in-agile-and-scrum.

Considering all the things are followed and are available in JIRA, now we have below items with us to track:

·         Product Backlog/Roadmap.

·         Bugs/Issues in released Product.

·         Current Sprint:

o   Stories, Defects, Sub-Tasks, Testing, Bugs etc.

·         Miscellaneous:

o   Quality Stats.

o   Performance stats.

I want to limit this article about Which things to be tracked in a Sprint using JIRA.

This who knows about JIRA Issue creation and its workflow usage, can move to next part of this article.

Please refer below diagram about creation of different issues and using JIRA attributes.

Every JIRA tasks has workflow associated with it. It is good to have information about respective workflow statuses.

Please refer below for EPIC/Story and can be customized based on your organizational strategy.