Skip to main content

How do you suggest we organize and use Scrum?

Last post 10:54 am October 7, 2013 by Nissi Vieira Miranda
8 replies
05:48 pm December 21, 2012

All of the software developers in my company recently took general scrum training. Several of us also took product owner and scrum master training.

My team consists of 5 developers and one product owner inside our company. We are contractors, and there are several stakeholders we deal with regularly at the company we do work for.

Our software products consist of plug-ins for an existing commercial software product. We all use similar technology, but each plug-in is different and usually has a different stakeholder at the parent company. We are currently working on 4 different plug-ins. Each plug-in sub-team consists of 1 - 2 developers.

We have decided that we would like to use Scrum beginning in January 2013. We currently use Visual Studio requirements, tasks, change requests, and bugs to manage our work items.

1) Do you think Scrum is appropriate for our situation?

2) How should we manage our product backlog? One big backlog, one backlog for each plug-in...? Each stakeholder will have input into prioritizing the backlog for their plug-in.

3) Would it help us if we switch to the Visual Studio Scrum template?

I can think of a lot other questions, but maybe this is enough to get started. Thanks in advance for your help.

09:48 am December 22, 2012

Hi Mark,

those are a lot of questions - and they are not easy to answer. There is no clear "yes" or "no" in your case.

1) Scrum will work for you. However, you will quickly unearth problems in your current setup that lead to surfacing impediments. If you don't solve any of them, you will not reap much benefit from Scrum.

2) Each team should only be fed from one Backlog. On the other hand, every product should have it's own Product Backlog. There goes your first problem: Do you have many products or is it a single one? If there are multiple products, should the small teams (1-2 people) be fully dedicated to them or will they switch between products?
I cannot give you a clear recommendation here. Ponder the questions and try something - if it doesn't work, try something else. Your Product Owner will need quite some support from you though.

3) I don't give much on tools. Sticky notes on the wall are still the most productive way to plan and organize stuff. If you go for a tool (e.g. VS) just make sure you don't let the tool fool you. Don't change your processes because a tool forces you to.

If you have more questions, we are happy to discuss them with you. You probably will get better discussions though, if you just ask a single question per thread - that's at least what I would prefer :-)

Merry Christmas!


04:02 pm January 1, 2013

Hi Mark

I'd agree with each of Dominik's points, but also point out that you need a Definition of Done that is appropriate for all items across the shared backlog.

Getting the Development Team and the Product Owner to agree on a DoD for all plug-ins, and which takes each item to the point where it is potentially releasable, will shake out a lot of issues and it should help a lot in decision making.

07:16 pm January 31, 2013

Hey Mark,
Your development team is awfully small (5 correct?). Normally your DT should be +- 7. Do you have enough resources allocated?

05:32 am February 2, 2013

Your development team is awfully small (5 correct?). Normally your DT should be +- 7. Do you have enough resources allocated?

The appropriate DT size for Scrum is 6 + or - 3, so between 3 and 9 developers. As it turns out the smaller end of that range is much more productive than the top end of that range.

In summary, small dev teams are GOOD!

05:48 am February 2, 2013


It's hard giving advice without knowing full context. I coached a team with a similar situation to yours, except the products were mobile apps instead of plugins. That team had a really hard time having ~8 product backlogs, so they consolidated it into one "team backlog." Because they wanted to keep the team working together as a team, have a consistent focus for a while, and keep product skills cross-pollinated, they focused on release themes, and tagged their product backlog items according to the release theme the PBI belonged to.

So, as an example... Products(in your case, plugins) A, B, and C.
Sprint 4 might include PBI's tagged with "A v3.1" (Release 3.1 of product A), "B v5.2", etc
Sprint 5 might include PBI's tagged with "B v5.2" (finishing up the release), "A v3.2"(small), and "C v1.7"

The releases were done completely separate from the sprint end boundary(and occurred 1-2 times a sprint), though all code was "potentially shippable" pretty much all of the time. Scrum says that the end of sprint increment must be potentially releasable, but Scrum does not prohibit you from releasing any number of other releases at any time. This is something a lot of teams don't understand. At the minimum, the end of sprint increment must be potentially releasable. How many other releases you want to do is up to you.

The focus on one(or at max two) product at a time allowed for teamwork, swarming, cross pollination, and focus. The releases were small incremental releases so that no one product would "hog" the team's bandwidth for very long(or if it did, for good reason!), and this allowed the releases to essentially be ordered by value on the product backlog. It also allowed value to be assessed across products.

As you can imagine, the downsides of creating small separate teams/backlogs can be that the most valuable stuff is in product A, but there are only 1-2 A developers. Meanwhile B and C developers are working on things not nearly as valuable, because they are restricted to working on their own products. Also, this tends to silo the tribal knowledge about the products and doesn't allow for as much parallel development and bottleneck removal. Having said that, there may be a good reason to go with separate teams, so there are not clear cut answers here. There may be more to your context than we know.

Like Dominik said above -- start with something quickly and try to iterate towards a better way.

09:45 am October 7, 2013

Hey Mr. Bradley,

I didn't understand. You're saying that you can have more than one release into one sprint, being one of them the potentially releasable increment?

Thank you for the attention!

10:43 am October 7, 2013

I think Charles is saying that there can be many increments delivered over the course of a Sprint, each of which may be potentially releasable. The expectation is that the Sprint Plan (i.e. the Sprint Backlog in combination with the Sprint Goal) should be satisfied by the end of the Sprint. However there is no rule against providing some of those deliverables earlier.

I'd like to make this additional point though. During Sprint Planning, the Product Owner has the right to expect only one potentially releasable increment by the end of the Sprint. He or she should does not have the right to expect any intermediate deliverables. This is because the Development Team wholly own the Sprint Backlog, and they wholly own their plan for delivering a potentially releasable increment by the end of the Sprint timebox.

The Development Team may choose, at their discretion, to provide earlier increments for potential release by the Product Owner. They should advise the Product Owner of any such decision on their part as soon as possible. The Product Owner will also need to advise the team regarding any in-sprint opportunities for the release of business value.

10:54 am October 7, 2013

Thanks Ian! Was very helpful. =]

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.