Just discovered your channels and videos Gary... I'm a PM a start-up digital games company and your content is incredibly helpful. Please keep up the fantastic work!
My team uses two week sprints, but this past Spring I worked with a team in a weekly format. Though I have never worked anything longer than two weeks, it feels like a sweet spot.
@@Developmentthatpays I find that if it is a week people can get burned out because people find that we'd be more working on the process than the actual work.
@@Developmentthatpays We did not hold all the ceremony, no. We had a weekly demo session where we also assigned ourselves work for the next sprint in the same session. Since we were a small dev team of three people, there wasn't much friction when it came to getting everyone on the same page.
In our team we are used to 2 weeks sprints but some times we go with 3 weeks sprints if the development is going to work to new chunk of project which is totally new and have not had any experience implementing that before then we plan the improvements in the next sprint which is indeed a 2 weeks sprint .
We do 2 week Sprints, thanks for the idea of "No changes are made that would endanger the Sprint Goal". There is always a tendency of people in my team to be adding things into the Sprint during it and this is a very good idea I can always emphasize to them. Thanks a lot!
we are a full remote team, we do 2 weeks Sprints and one week hackaton kind of Sprint every 4 to 6 months that we all meet on a location, awesome videos.
two weeks as well, not only that, it is aligned with the executive level sprints which are also two weeks though the meetings are staggered otherwise everyone gets nothing done the whole day. Execs will discuss the strategy and talk about higher level chunks usually with the product owner and the dev team discussions the day after use the discussion as input to help with their own sprint team plannings for the retro and sprint planning.
@@Developmentthatpays we just started it recently. Our organization as I have generally noted is growing up to scrum organically rather than being forced upon by consultants. So far so good though. Some key things... The main reminder I put up again was that the project owner (rather than product owner because execs deal with projects) was that they are responsible and have to be in control of their task board. In there, they should make sure they know if anything moves around in there regardless if it is assigned to them or not, and actually the assigned is more of a tool for the project owner to know who to "hunt" for in order to move things forward. Not exactly sure if that's what you said in the Product Backlog video. The project owner [theoretically] does not do any of the actual development work. However, the project owner must know what it is they are telling their development teams to do before it goes to the Sprints. One issue we have was a bit of a tooling gap because I don't want the execs to learn yet another tool so we have two systems at the moment. ODOO and Azure DevOps. Because of this there's two stages for the product backlog, but it keeps Azure DevOps backlogs a little more pristine for the developers as it won't have any back and forth with the executives. Scheduling wise we do it this way with two week sprints THURSDAY = Exec Sprint End/Sprint Planning here we discuss at a high level some key things. The product owners are there along with the Scrum master (though I may change my title to Agile Coach because it sounds less arrogant). 1) which ones we have completed that would impact exec level stuff. Generally bugs unless it had a major customer impact **cowers** do not get brought up here. Some things that would go here are... need for analytics, marketting materials, *physical* deployments, sales support etc. 2) which ones were not completed and will continue next sprint because reality 3) which ones are expected to be added in next sprint. (Now this list is sort of special in that this drives what will be fed into the development sprint) 4) which ones that are elaborated that are not going to be added into the next sprint because the project owner does not believe there'd be enough time for his team to implement. Some discussion about priority may occur here in case some other exec may want something sooner or designate a deadline. 5) which ones have started discussions already but not fully elaborated. Elaborated entries meet most of the INVEST criteria. The order of the list would be shifted according to priority as discussed by the execs. They'd also have a chance to be a squeaky wheel and move items from the inbox column over to the discussion column. FRIDAY = Dev sprint planning + review + retro Here we do things a little backwards, primarily because reality has some of our contract staff in the other side of the planet. So we do the planning early in the morning in place augmenting our dailies. Though reality is this day is a write off for development generally. I don't bother with marking it as an off day though, I have our capacities lowered to 5.5 so the time is more or less compensated. Here the Project Owner now Product Owner shows the team the initial cut of next Sprint plan based on the exec meetings. Though it does not mean he did the planning himself, there's no reason for them not to contact with the other dev team members or even get refinements from other parties to make it a little more accurate so less changes during the actual sprint planning. Then we just do the planning. The dev team shows off the product increment to the Product Owner and other interested parties later on (usually after lunch) and then we do the retro the order of the two may change depending on people's availability.
Hi Gary, I am "new" in this context of Agile / Scrum / Kanban, etc. I didn't understand well the concept of a "potentially releasable increment". As I have watched in one of your great videos before, where you have outlined that one of the key characteristic of "being agile" is exactly the deliverables of the increments to customers - due to the systematic feedback collected by product owner. I assumed that "release" these increments during the life-cycle of a project would be "imperative" in scrum - as it is exactly a key benefit against the waterfall mindset/framework, from my humble view...Could you please clarify to me why release seems "loose" now? Thanks. Your videos are extremely didactic, a perfect mix of good sense of humour and professionalism, please keep making them.
Hi Gary, 2 week sprints with one team and Scrumban with the other. For the team running 2 week traditional sprints What are your views on dropping subtask estimation and having task/story level estimates only?
Development That Pays Hey Gary, they are doing the later estimate the story/task level then subtasks. I am finding that it’s extending planning sessions for little payback and also creating a culture where people focus individually on sub tasks not overall story/task level value for the customer
I think I said "the team"... but "the PO" may be more correct. Here's what the Scrum Guide says: "Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it."
I find that month sprints can get pretty hairy if you have a strong development team. However, working for the large bureaucratic organizations (e.g. government) reduces the analysis paralysis that would occur. The thing to watch out for is whether your task list in a sprint grows larger than 2 screenfuls. Because at that point, it would mean that your team is getting more efficient and the work is being broken down better in which case I would evolve the organization to have shorter weeks. I don't believe in having hard rules that a sprint should be consistent because reality. However, it shouldn't change too often unless everyone is in agreement
Remember to grab your FREE Scrum Cheat Sheet --> www.developmentthatpays.com/cheatsheets/scrum
Just discovered your channels and videos Gary... I'm a PM a start-up digital games company and your content is incredibly helpful. Please keep up the fantastic work!
I love that you have closed captions on your video, thank you very much.
Thanks for noticing!
My team uses two week sprints, but this past Spring I worked with a team in a weekly format. Though I have never worked anything longer than two weeks, it feels like a sweet spot.
I'd be interested to hear how the weekly format played out. Did you do all of the events - inc. Review and Retro - every week?
@@Developmentthatpays I find that if it is a week people can get burned out because people find that we'd be more working on the process than the actual work.
@@Developmentthatpays We did not hold all the ceremony, no. We had a weekly demo session where we also assigned ourselves work for the next sprint in the same session. Since we were a small dev team of three people, there wasn't much friction when it came to getting everyone on the same page.
In our team we are used to 2 weeks sprints but some times we go with 3 weeks sprints if the development is going to work to new chunk of project which is totally new and have not had any experience implementing that before then we plan the improvements in the next sprint which is indeed a 2 weeks sprint .
We do 2 week Sprints, thanks for the idea of "No changes are made that would endanger the Sprint Goal". There is always a tendency of people in my team to be adding things into the Sprint during it and this is a very good idea I can always emphasize to them. Thanks a lot!
You're most welcome!
we are a full remote team, we do 2 weeks Sprints and one week hackaton kind of Sprint every 4 to 6 months that we all meet on a location, awesome videos.
two weeks as well, not only that, it is aligned with the executive level sprints which are also two weeks though the meetings are staggered otherwise everyone gets nothing done the whole day. Execs will discuss the strategy and talk about higher level chunks usually with the product owner and the dev team discussions the day after use the discussion as input to help with their own sprint team plannings for the retro and sprint planning.
Does the exec-level-feeding-in-to-dev-level work as well as it sounds like it would?
@@Developmentthatpays we just started it recently. Our organization as I have generally noted is growing up to scrum organically rather than being forced upon by consultants. So far so good though. Some key things...
The main reminder I put up again was that the project owner (rather than product owner because execs deal with projects) was that they are responsible and have to be in control of their task board. In there, they should make sure they know if anything moves around in there regardless if it is assigned to them or not, and actually the assigned is more of a tool for the project owner to know who to "hunt" for in order to move things forward. Not exactly sure if that's what you said in the Product Backlog video.
The project owner [theoretically] does not do any of the actual development work. However, the project owner must know what it is they are telling their development teams to do before it goes to the Sprints.
One issue we have was a bit of a tooling gap because I don't want the execs to learn yet another tool so we have two systems at the moment. ODOO and Azure DevOps. Because of this there's two stages for the product backlog, but it keeps Azure DevOps backlogs a little more pristine for the developers as it won't have any back and forth with the executives.
Scheduling wise we do it this way with two week sprints
THURSDAY = Exec Sprint End/Sprint Planning here we discuss at a high level some key things. The product owners are there along with the Scrum master (though I may change my title to Agile Coach because it sounds less arrogant).
1) which ones we have completed that would impact exec level stuff. Generally bugs unless it had a major customer impact **cowers** do not get brought up here. Some things that would go here are... need for analytics, marketting materials, *physical* deployments, sales support etc.
2) which ones were not completed and will continue next sprint because reality
3) which ones are expected to be added in next sprint. (Now this list is sort of special in that this drives what will be fed into the development sprint)
4) which ones that are elaborated that are not going to be added into the next sprint because the project owner does not believe there'd be enough time for his team to implement. Some discussion about priority may occur here in case some other exec may want something sooner or designate a deadline.
5) which ones have started discussions already but not fully elaborated. Elaborated entries meet most of the INVEST criteria. The order of the list would be shifted according to priority as discussed by the execs. They'd also have a chance to be a squeaky wheel and move items from the inbox column over to the discussion column.
FRIDAY = Dev sprint planning + review + retro
Here we do things a little backwards, primarily because reality has some of our contract staff in the other side of the planet. So we do the planning early in the morning in place augmenting our dailies. Though reality is this day is a write off for development generally. I don't bother with marking it as an off day though, I have our capacities lowered to 5.5 so the time is more or less compensated.
Here the Project Owner now Product Owner shows the team the initial cut of next Sprint plan based on the exec meetings. Though it does not mean he did the planning himself, there's no reason for them not to contact with the other dev team members or even get refinements from other parties to make it a little more accurate so less changes during the actual sprint planning.
Then we just do the planning. The dev team shows off the product increment to the Product Owner and other interested parties later on (usually after lunch) and then we do the retro the order of the two may change depending on people's availability.
Thanks, Gary, you made a massive topic from my syllabus seem to be merely a problem to sprint through ;)
Excellent! Lovely comment!
Gary great episode, like always!
Thank you!
How relevant are sprints for packaged application's implementation like Oracle ERP, SAP etc?
Hi Gary, I am "new" in this context of Agile / Scrum / Kanban, etc. I didn't understand well the concept of a "potentially releasable increment". As I have watched in one of your great videos before, where you have outlined that one of the key characteristic of "being agile" is exactly the deliverables of the increments to customers - due to the systematic feedback collected by product owner. I assumed that "release" these increments during the life-cycle of a project would be "imperative" in scrum - as it is exactly a key benefit against the waterfall mindset/framework, from my humble view...Could you please clarify to me why release seems "loose" now? Thanks. Your videos are extremely didactic, a perfect mix of good sense of humour and professionalism, please keep making them.
BTW welcome back
Thank you. Yes, it's been a while ;)
Hi Gary,
2 week sprints with one team and Scrumban with the other.
For the team running 2 week traditional sprints What are your views on dropping subtask estimation and having task/story level estimates only?
Does the team estimate Tasks and aggregate them for Story estimates? Or does it estimates Stories first, Tasks afterwards?
Development That Pays Hey Gary, they are doing the later estimate the story/task level then subtasks. I am finding that it’s extending planning sessions for little payback and also creating a culture where people focus individually on sub tasks not overall story/task level value for the customer
"potentially releasable" increment is actually released if the team says so? or just the PO?
I think I said "the team"... but "the PO" may be more correct. Here's what the Scrum Guide says:
"Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it."
@@Developmentthatpays now I agree ;)
@@lutaseb - Good catch. Thank you!
A true Gary 💪💪
:)
We do one month sprints.
Is that a calender month, or four weeks?
I find that month sprints can get pretty hairy if you have a strong development team. However, working for the large bureaucratic organizations (e.g. government) reduces the analysis paralysis that would occur. The thing to watch out for is whether your task list in a sprint grows larger than 2 screenfuls. Because at that point, it would mean that your team is getting more efficient and the work is being broken down better in which case I would evolve the organization to have shorter weeks. I don't believe in having hard rules that a sprint should be consistent because reality. However, it shouldn't change too often unless everyone is in agreement
HR team working in 2 weeks sprint here.
Always like a non-software example. Many thanks!
2 week sprints
Thanks, Stefan.
2 weeks
Thanks Nick
2 weeks