My new PM gets annoyed when I call it mini waterfall, but like, if I'm spending half the sprint waiting on things to get in QA, and then I get flooded with tests to write, isn't that waterfall?
Devs can pick something from next sprint to pull in and work on to be occupied, but there's only so much automation I can preplan without code in front of me feature complete from a dev. I was able for one sprint to argue that I could fix a bug as a dev before the QA flood, but that hasn't really worked since (because I don't feel like arguing for work every single sprint planning)
Do you think, getting flooded is a direct result of using Jira or is it related to the way the project is structured? Getting flooded is always a bad thing (and probably your PM should get annoyed by that), but I believe that could happen to you with any other tool.
Jira's a variable, for sure, but it's mostly management.
Mainly, Jira metrics are what run our management (actual HR managers, not PMs). Because of needing set qualitative measures to judge teams on, no one is allowed to use anything other than the Approved Jira Workflow For Scrum Teams.
My team is over 50 sprints in with a fleshed out backlog... there's no reason other than politics for why we can't go Kanban. And Kanban is pretty much the only way to stop that flood since more things can ebb and flow naturally rather than in structured time frames. The alternative would be to make stories ultra tiny to get the burndown started earlier, but that would cause a dramatic drop in effectiveness since we'd be bogged down with the process of it all.
While Jira does have Kanban boards, the concept of something not being done by the end of a sprint is too ingrained in how teams are deemed successful or not.
Yeah, the devs aren't considered responsible for having completed testing. As you say, they pull in additional work for the sprint rather than making sure the rest is DoD.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My new PM gets annoyed when I call it mini waterfall, but like, if I'm spending half the sprint waiting on things to get in QA, and then I get flooded with tests to write, isn't that waterfall?
Devs can pick something from next sprint to pull in and work on to be occupied, but there's only so much automation I can preplan without code in front of me feature complete from a dev. I was able for one sprint to argue that I could fix a bug as a dev before the QA flood, but that hasn't really worked since (because I don't feel like arguing for work every single sprint planning)
Do you think, getting flooded is a direct result of using Jira or is it related to the way the project is structured? Getting flooded is always a bad thing (and probably your PM should get annoyed by that), but I believe that could happen to you with any other tool.
Jira's a variable, for sure, but it's mostly management.
Mainly, Jira metrics are what run our management (actual HR managers, not PMs). Because of needing set qualitative measures to judge teams on, no one is allowed to use anything other than the Approved Jira Workflow For Scrum Teams.
My team is over 50 sprints in with a fleshed out backlog... there's no reason other than politics for why we can't go Kanban. And Kanban is pretty much the only way to stop that flood since more things can ebb and flow naturally rather than in structured time frames. The alternative would be to make stories ultra tiny to get the burndown started earlier, but that would cause a dramatic drop in effectiveness since we'd be bogged down with the process of it all.
While Jira does have Kanban boards, the concept of something not being done by the end of a sprint is too ingrained in how teams are deemed successful or not.
Yeah, the devs aren't considered responsible for having completed testing. As you say, they pull in additional work for the sprint rather than making sure the rest is DoD.