Project Planning and Scrum

 One of the major drawback of the Scrum Method is that it overlooks the fact that many changes have to be done in a longer period of time and those big project has to be managed in a different lifecycle across multiple sprints.

Here are some possible ways:

Estimation Task

Estimation is taking time from engineering team.  Just for initial investigation, the duration should be considered.

One possibility to create JIRA tasks for estimation. The time taken is tracked in the daily standup as well.

These tasks have to be prioritized against other tasks.  

If it is important as we have to use the estimation or assessment for future planning or feedback to customers, It should be reflected in the board.

This type of ad hoc request needs to prioritized to protect resource from distractions.

Research Projects

We may have not yet created the branches and we may put the initiative to be released in a future sprint, but if any task required for discussing, brainstorming, gathering feedback, reviewing the different approaches, we should track these activities as well.   

Remember that we are taking resources away from the current sprint that has the branch open for checkin.  These resources are still contributing without checkin any line of codes.

A product feature is plan for a future release does not mean that there is no activity (or investment) in the current release.   Not everyone is working on the current release since we are invest for the future.

Merge Often even the feature is not complete

As long we have hide the features, having the old code and new code coexist and allow them to be switch on/off for testing may be a way to gathering feedback and also stablize the code earlier.

Merging a big branch into the main will make the merge longer and riskier.

Run multiple sprints in parallel

Different sprints may have different deadline.

But we need to be careful about this.

I don't like scrum as it tends to be very political.  It is easily to get someone who are not really capable to be involved in a project to claim that they are scrum master, and organize projects by these scrum masters.

Teams should own their scrums and scrum method is not the way to push these people or for them to gain training.

I think that those activities that are sharing the same resource pool (team) have to be placed on the same board.