One Item Over Multiple Sprints
Not sure how to handle this one. I moved into a new team and normally would break something that goes over multiple sprints into smaller items that can be accomplished in a two week sprint.
Some team members are resources for other project teams and are involved in the design phase. These design / development discussion efforts sometimes drag on for weeks, if not months, yet we still have to be engaged and involved as necessary, but ‘we’ are not necessarily in control of when our time is needed during any given sprint. Thus, it is a fact that we do have users stories that span multiple sprints. Also, it is not easy to carve up these types of efforts into ‘smaller pieces’ that only are relevant to the ‘active sprint’, because in many cases we don’t know what is going to be required of us during a given sprint. There is a meeting each week and a new task to accomplish may come up.
Is it okay to just let it run sprint to sprint or is there something else I should be doing. I would appreciate any thoughts or suggestions.
Thanks,
Gary
How is this mode of operating affecting focus and productivity?
Do you feel that agile software development values and principles, and the Scrum framework are being upheld?
"Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team."
"Responding to change over following a plan"
"The best architectures, requirements, and designs emerge from self-organizing teams."
"Working software is the primary measure of progress."
"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product."
"The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team."
"During the Sprint no changes are made that would endanger the Sprint Goal"
What influence or empowerment do you have to affect change to improve the situation?
+1 Alan
Along those lines, it is not ok to allow stories to just run from sprint to sprint. The team should be dedicated to their forecast of sprint work.
Why is it necessary for your team to be involved in the design and development discussions of other teams?
Why is your team not in control of outside needs for team member involvement? Why are you, as their Scrum Master, unable to sequester your team so that they can focus on their own sprint work?
Any outside interference that is taking capacity from your team must be highlighted (as often and as visible as possible) as a significant constraint on your team's ability to do work.
And you simply cannot gain any insight into how productive your team is (i.e. - velocity) when they're constantly getting pulled in different directions. The context-switching alone is a huge drain on their productivity.
It looks like at high level team is using scrum but not adhering to scrum principals. Scrum master should use legitimate power to control behavior whenever possible.
1. If team cannot accomplish many activities in 2 weeks, check what should be the length of your sprint.
2. Team members should spent more time in identifying tasks in the sprint planning meeting and identifying tasks where design expertise needed. It would give some more visibility to design experts on what is coming up.
3 Is meeting/ discussion/ design decisions are based on criteria? What is the outcome of any meeting conducted to discuss design issue? What is the root cause that drag discussion into weeks?
I think it matters if we are talking about "items" or "stories." An item that spans sprints is usually an oops; a story that spans sprints...well...how many times does the Scrum Guide reference stories?
Are we talking about a rare user story that has a lot of precursors to it or external dependencies, and where it doesn't make sense to call anything less a story, so the developers have broken out the work into multiple backlog items and are making progress toward a future target (earning points) while delivering other functionality in every sprint?
And is it better to enforce a "rule"...or let the developers figure out how far they should decompose backlog items?
"Story" has a real definition, but the product backlog includes items that aren't stories. It drives me a little nuts to see the concept of stories perverted by equating it to any work -- in my experience, those teams often slide on delivering functionality to users.
That said...unless this is a technique to fill lag time with unimportant but nice-to-have work, I would be really worried about a habit of letting things slide from sprint to sprint -- if the items can't be logically decomposed so that there is progress, the team is probably wasting a lot of time starting things they can't earn points on. This would be a really good discussion for a sprint retrospective.
Thanks for the feedback. Still trying to grasp how they are using Agile in this department. It seems that certain things become high priority depending on who it is escalated to. Also, the amount of unplanned work from other teams is quite large and cannot be moved to next sprint. I have them reviewing some of the blocked items that are months old to see if they can be put in backlog. If it is four months old, and someone is not sending you information on their request, then it is not important.
There is Agile training coming up for the department. It should be interesting to see how they react to the training.
If it is four months old, and someone is not sending you information on their request, then it is not important.
That is a very wise practice, Gerrit. The PO and the Development Team should work to keep the product backlog fresh and current. Delete older backlog items that have not been touched in months. They are obviously a low priority if they have not been looked at recently, and if someone complains, then it is minimal effort to add it back.
I would ask though, why is there so much "unplanned" work coming from other teams? What can be done to change it from "unplanned" to "planned"? What can be done to reduce the dependencies between teams?
"Story" has a real definition, but the product backlog includes items that aren't stories. It drives me a little nuts to see the concept of stories perverted by equating it to any work
I agree. For so many terms.
A common language referring to the process must be shared by all participants
>> If it is four months old, and someone is not sending you information
>> on their request, then it is not important.
>
> That is a very wise practice, Gerrit.
Definitely. It is a matter of backlog management hygiene. If you haven't already done so however, you should establish this as a matter of policy. You don't want to be bitten by any comeback further down the line. In my experience most managers are comfortable supporting this as the benefits to their teams and/or departments are fairly clear, and it is a difficult policy to argue against.