We are trusted business agility advisors, supporting organizations in their quest for speed and quality since 2007. We offer consulting and training covering all Agile, Lean and DevOps topics. We specialize in executive leadership support and organizational agility, helping to implement lean portfolio management, project to product transformation and value flow.
Thank you for that presentation on understanding and implementing the basics of an agile portfolio management structure in a company. I recently read the Phoenix Project and they reference concepts likes those you mentioned, but I feel I now better understand the reasoning and positive attributes of leveraging this type of planning structure.
If the question is whether you can use Gherkin to develop executable specifications, then the answer is yes. That is the primary purpose of using Gherkin with BDD.
I thank you and apricate you making this video, I found this information useful, and your presentation easy to follow, yet thought provoking as well. Your abilities shine thought in the video, and I am great to have run in to your content.
What about when QA has a large work item for regression testing prior to a release? The QA team will be occupied with regression and won't have bandwidth to test new Dev work, and Dev is not participating much in regression except to fix defects. How should the team's estimate regression items with a large level of effort?
While this sounds great from a scrum master's perspective... As a developer I am torn on this. Asking the team to estimate the complexity of an unknown task is ridiculous to me. Points on a spike are just a vague and unreal way of carving out time.
The objective of the spike is to get the team to better understand the complexity of a story before they have to execute on it. As Lisa says, the spike should be time boxed - say 3 days. And at the end of the time box, the team should know more about the story and be able to estimate without feeling like it's nothing more than a huge guess. If they feel like the time box wasn't enough and they need more, then open up another spike in the next sprint, but be careful of falling into analysis paralysis! Hope this helps!
Great glad you enjoyed the talk. I find I use "Agile" techniques in my life all the time. Personal fan of using work "timeboxes" through the Pomodoro Technique en.wikipedia.org/wiki/Pomodoro_Technique
Yes! If you have edit rights to the dashboard, just select "Add Gadget" and search for "velocity". Depending on what your Jira admin has enabled, you should see several options that can be configured to suit your needs. Good luck!
Thank you for your kind words! We will be releasing new options for you to leverage the Agile VMO in 2023. To stay in the loop, sign up for our newsletter here: lithespeed.com/newsletter/
I've definitely been trying to encorporate practical application of scrum and agile into my life. I must say some gems to me are toastmaster clubs to improve public speaking and Kanban in form of my "to do" list in my day to day life. This video was really helpful. Great tips!
I think I met Russ some 22 years ago. We were in the same educational pool at Andersen Consulting in Chicago, St. Charles and there was a good friendship building over those few weeks. He's a really great guy. I wonder if he still plays and sings 'brown eyed squirrel' on his guitar. Good to see he's still in software development! Many greetings!
Thank you for sharing, very useful. I have a question, How will you evaluate the success of the change of a Product Backlog in Jira? Thank you so much in advance.
Hey Lisa. That was a detailed explanation. I have a question here. Is it fine to change/update the story points in between a sprint? We faced a situation where team members realized that they have consumed more effort than estimated(no change in scope) and opted to have the story points changed from 3 to 5 while closing the issue. Is this alright? If not, what would be the resolution in such a situation?
You are right. In contexts that involve planning and coordination among multiple ARTs, the Solution Train Engineer (STE) serves as an Lean-Agile leader (much like the RTE), and beyond fulfilling the core responsibility of the role, which is to prepare for and support large solution PI planning and delivery, the STE serves as coach to the RTE community, and other ART roles looking to deepen their understanding and application of lean-agile principles and practices. While there are undeniable similarities between the RTE and STE roles in terms of their role as Lean-Agile leaders, the STE typically interacts with higher-profile stakeholders and is less likely to be directly working with teams on a daily basis, and is less embedded directly in the execution context. Most of the events being facilitated by the STE involved selected ambassadors from the trains.
Spikes can be complex. I think if an estimate is put on a spike is should be a timebox. Once the time is up the person talks about what they learned with the team and they decide if more time should be given or if enough has been learned to move forward.
Thanks for your comment, Michelle! Principal Agile Coach Raj Indugula here. I agree with you. A spike is a time-boxed investigation conducted by the team to better understand a given story (they don’t know enough about the story to estimate it). Typically, spikes are not estimated like user stories, but time is set aside by the team to run the investigation, and the output of this time-boxed effort is better understating of the original story along with an estimate.
Thanks for sharing this on RU-vid. Got some pretty good ideas of which metrics to look for. It's unfortunate that the majority of these reports are only applicable to a scrum board.
Story vs task, how my team has differentiated between the terms over the years: A story is a product requirement that caters to a persona or a user, or a type of user within the product. For example. As an analyst, I want to be able to view A and B side by side. As a manager, I want to see a summary of all work completed by analysts. A task is something that needs to be done but isn't tied to a persona for the application. For example, Node Upgrade to Version X.XX. Or migrate data from Cluster 1 to Cluster 2. Switch Unit Testing libraries from Mocha to Expect. Tech debt is another example: Refactor/Rewrite logic in some module to apply developer best practices. Tasks don't check off boxes for user personas, nor does your product owner or stake holders ever want to be bothered with such things, typically. Also, developers are not application personas, typically. In our opinion, it has nothing to do with how many developers can work on an issue.
Great information. Thank you for this video. I have never heard the title "Scrum Master" before tonight, I was job searching and I found myself here. I learned a good amount from this and I thank you again.
Hi Dom - thanks for watching! Glad you found the information helpful. We offer Scrum Master training and resources at our website. Feel free to check it out & Contact Us with any questions. lithespeed.com/
What a great conversation. Enjoyed thinking back on that experience with you both, and loved hearing your thoughts on the future of distributed Agile. I was fortunate to have been part of that Agile transformation 14 years ago; the people and experiences pivotal in shaping my appreciation for how valuable Agile can be. So many of the lessons learned continue to influence how I strive to serve teams even today. No surprise to hear mention of the importance of people from Michael in a discussion about Agile, good to know some things haven't changed in 14 years :-)
