2

Summary

We're a medium sized company that has a development team of five team members. We recently started learning/employing the Scrum method to our R&D department.

Our core team has one project, while each employee has individual task and projects. Some of those individual projects are only big enough for a single developer to complete.

Additionally, a single developer may be supporting a product they released individually.

Furthermore, we currently use a JIRA Scrum board to track our progress in our core team project, while we each use individual JIRA Kanban boards to handle our individual tasks/projects.

We found that it's easy to go over the core team's project during the sprint review, but it's difficult to have visibility into our daily tasks and projects not related to the core project.

Should we utilize a single Kanban board that pulls in all of our core teams Scrum board issues, and all of our other non-core team tasks/projects?

Then we go over all issues in the all-inclusive Kanban board during our sprint review meeting? If so, how should we filter our Kanban board? Updated within a certain time frame, labels, etc?

Or should we use a single Scrum board and force the entire team to plan and estimate both the core team's project and all the individual tasks/projects? What happens when new support issues occur during the middle of the sprint? Do we adjust the sprint scope mid-sprint?

Question

What method of grouping should we use to present both our core team's shared project, and each developer's individual tasks/projects while preserving Scrum estimation and planning?

Improve this question
3
  • 5
    Does it actually make sense to go over all individual projects together? Ask yourself whether the benefits of having these projects discussed in group-wide meetings outweigh the downsides of having longer group-wide meetings. From my experience, trying to include to much individual work leads to monologues with the rest not really listening and without any discussions.
    – larsbe
    Aug 15, 2017 at 14:47
  • That's a great point. I think the reason the meetings would be too long and/or including people who aren't associated with the individual projects is why we have individual projects. For example, sometimes an individual would work on development that is on a single file and will take a limited amount of time. Alternatively, I'm aware SCRUM would help bring perspective to the implementation method.
    – SaundersB
    Aug 15, 2017 at 15:05
  • Has the team discussed mixing a combined project with individual tasks in a sprint and do you want to keep it that way? You could move to a sprint where all tasks are on 1 board and a team member always picks the most important task to work on. Incoming support tickets are different. Perhaps the team can reserve an amount of time of the for such tasks.
    – Kwebble
    Aug 28, 2017 at 20:47

2 Answers 2

Reset to default
1

The scrum team should have a fixed goal for the sprint which everyone is contributing to. Build this feature, complete this release... because this is real life team members have other commitments to the business, that's ok - but everyone needs to judge how much time/effort they can commit to the scrum team each sprint. It sounds like you're handling this quite nicely by splitting out this additional work.

However, the next logical conclusion of this is that only work that is part of the scrum team's projects should be tracked on the scrum board and discussed in daily standups. There is absolutely no point in your team lead talking about interviews or your infrastructure guy talking about servers in a daily standup for a team which is focused on completing the next feature.

This isn't to say that it this work shouldn't be tracked. But that should be done in different team standups or 1:1s with the project manager/line manager and it can be brought to team members through chats, grapevine, and official communication without taking up those valuable 15 minutes.

Kanban boards can be used (if you like) but don't put them on the main board, create another board in JIRA or even spin up a few trello pages.

Something we've been using recently is a using a monitor during the standup, the display shows the scrum board and if it's not on the board it's not discussed (within reason obviously). This helps focus the meeting and keeps the daily standup brief and concise.

Improve this answer
0

Try a Scrum/Kanban combo board based on Scrum:

Scrum/Kanban Wall

The tactic is to employ both a Scrum board and a Kanban board together on your team’s wall. Here’s how that may work. Have the product owner operate the planned Sprint forecast commitments through your normal Scrum process and board or wall. Now, pass the ever-emerging honey-do needs through another short process of work flow control: a) a brief discussion about the ‘story’ with the Scum Master and team either during the daily Scrum or in a separate huddle, and b) do a story point estimation on the item(s) the product owner brings. Then place those on a Kanban portion of the team’s wall or board.

or a ScrumBan board based on Kanban:

Scrumban: Release Planning Backlog to TODO list

Start with a Kanban board and add the Product Backlog to it. Convert the Release Product Backlog to a TODO list via a small planning session. Call for planning when the TODO list is getting empty.

References

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.