Really enjoying your videos as a new Scrum Master starting out and supporting digital delivery for the Government of Canada! Love these quick hits of knowledge, insight, and links to other great agile resources.
@AgileforHumans3 жыл бұрын
Awesome! Thank you!
@rajadas64323 жыл бұрын
Great insight. I liked the fact, the discussion was balanced, more context specific. Thanks for your awesome topics.
@rgwkenyon2 жыл бұрын
If you use story points as intended they are very powerful. Combining story points and cycle time works well to.
@rajadas64323 жыл бұрын
It would be great if you can discuss on following topic. Context: A team is using scrum to maintain a product. The product in its maturity phase. Team’s typical sprint works revolves around enhancing existing features, bug fixes and code refactoring. Most often the PBIs are unrelated. Challenges: Due to the unrelated nature of the PBIs, forming a sprint goal is extremely challenging. In absence of sprint goal, daily scrum turning into siloed status meeting. Idea of using kanban was declined by people at top!! Question: In absence of goal, team is not able to realign on daily basis and that’s leading to carry over. And unfortunately, carry over is red flag . Is there anyway to form a sprint goal and rally around it? I read your book, I liked your cool ideas on forming sprint goals. But this situation demands a creative solution. Thanks in advance.
@kylewilliams67692 жыл бұрын
Really interesting situation! My module is a pretty similar situation but we are still doing a fair amount of new feature creation but before I was hired they started using scrum and didn’t feel like it worked for them so they switched to Kanban but then they were really struggling with organization and maintaining focus on the vision and the lack of a clear vision so they brought scrum masters back in and are now using scrumban. We are still figuring it out but I think it’s going to work really well!
@user-vk3xc8qs8n2 жыл бұрын
I had the same problem with my project in a previous organization. They started pointing bugs. I guess someone, in another Scrum body, made a case for how one could point bugs even though our training suggested not doing that. As the project manager, I personally didn’t like it when bugs were pointed. It also made it wonky in them coming up with sprint goals. The other problem was with Sprint goals. One of the sprint goals would be to fix X number of bugs of a certain type. The ScrumMasters (who were also developers), really used story points and velocity. Unfortunately, they frequently only completed 60% of the committed work (project managers were not allowed to coach ScrumMasters, and the Agile coaches were not effective in enhancing predictability). So, I stopped paying attention to those metrics they pulled. I started using cycle time. That gave me a much more accurate picture although it wasn’t complete. Cycle time was easier to discuss with the sponsor as well since the sponsor was too high up to understand story points. They were more concerned about when the work would be done.
@reinholdmain2 жыл бұрын
I expected to hear the options
@AgileforHumans2 жыл бұрын
Flow Metrics are the recommendation: Cycle Time, Throughput, WIP Limits, and Item Age. Dan Vacanti's book - When Will It Be Done? - is a great place to start.
@michaelhandley80133 жыл бұрын
Can't wait for the hoodies!
@himadridebnath65142 жыл бұрын
Great discussion ! :)
@osnyzinho2 жыл бұрын
amazing! thanks!
@anthonyolaleye2 жыл бұрын
Thanks for this video, very interesting! For those of us that still use Story points, how can we assign a Story point without relating it to hours? In my experience they are joined at the hip. Can you elaborate on this?
@AgileforHumans2 жыл бұрын
It's really hard to avoid the comparison between story points and time. I would start here and see what's possible: kzbin.info/www/bejne/gpCwdoCpetaFftk
@Kezrush3 жыл бұрын
Q: Sans Story Point, what are some other plan-it-poker like facilitation techniques have you found productive?
@archiee13372 жыл бұрын
When do you assign tasks to specific team members? During the planning? During the sprint?
@AgileforHumans2 жыл бұрын
We answered the question here: kzbin.info/www/bejne/h4KUnX2MebSKpqs
@MrAkkim3 жыл бұрын
What is the best way to manage work that was started in a Sprint. But not completed at the end of a Sprint. What could be done to ensure already contributed effort is accurately reflected in the sprint that has ended?
@scottf90442 жыл бұрын
what is meant by "accurately reflected"? If you're concerned that individuals outside of your team won't know that any work was done...then stop worrying about that. Users are interested in completed work. Your team should be interested in completed work so they can get valid feedback. If you continually have unfinished work then discuss why. if you're wondering how to use partially completed stories in planning going forward then just use What's Left and bring that data into your Sprint Planning.
@dimitrismammis11083 жыл бұрын
Hmmm. A relative measure of complexity, where complex work is done so that the team can align and gain crossfunctional knowledge, insight, is not a bad tool or practice. There will always be people in business, whom I call numerologists; people only caring for numbers, looking into your "black box " process and trying to identify a number to exploit, to make a silly metric out of it to exert their power on the team. But as long as you are true to the common values and pillars and have gained autonomy, then tools are just tools. They should not create bad practice or intent, that is a people choice. No?
@AgileforHumans3 жыл бұрын
If there is a practice that has good intent but continually breeds bad behavior shouldn't we look for other options? You made a good statement: "They should not create bad practice or intent, that is a people choice". I like options are easy to interpret and that don't lend themselves to misinterpretation :). However, use what works!