Forums

By posting to our forums you are agreeing to the Forum terms of use.
How do you suggest we organize and use Scrum?
Last Post 07 Oct 2013 09:54 AM by nissivm. 8 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Mark Newman
New Member
New Member
Posts:2
Mark Newman

--
21 Dec 2012 04:48 PM
    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.

    Dominik Maximini
    New Member
    New Member
    Posts:64
    Dominik Maximini

    --
    22 Dec 2012 08:48 AM
    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
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:570
    Ian Mitchell

    --
    01 Jan 2013 03:02 PM
    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.
    J_Evans
    New Member
    New Member
    Posts:1
    J_Evans

    --
    31 Jan 2013 06:16 PM
    Hey Mark,
    Your development team is awfully small (5 correct?). Normally your DT should be +- 7. Do you have enough resources allocated?
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    02 Feb 2013 04:32 AM
    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!

    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    02 Feb 2013 04:48 AM
    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.
    nissivm
    New Member
    New Member
    Posts:9
    nissivm

    --
    07 Oct 2013 08:45 AM
    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!
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:570
    Ian Mitchell

    --
    07 Oct 2013 09:43 AM
    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.
    nissivm
    New Member
    New Member
    Posts:9
    nissivm

    --
    07 Oct 2013 09:54 AM
    Thanks Ian! Was very helpful. =]
    You are not authorized to post a reply.


    Feedback