How do you suggest we organize and use Scrum?

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!

Dominik

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.

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

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!

Mark,

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.

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!

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.

Thanks Ian! Was very helpful. =]