Відео

Ofc you release it then you release a dlc to ask ppl to pay for it

I understand that in the #noestimates approach, story size and sprint/development capacity are considered constants, correct? There also seems to be an assumption that we MUST complete our backlog items to deliver anticipated value! No?

thank you so much 😍😍😍

Nice example for BDD & TDD and non-IT field. Thanks

I would go with TDD in an actual world, but BDD in this case of hanging a shelf is more practical and faster with a quick mallet touch and alignment check. I would think in most organizations is the lack of awareness of TDD which drives development/QA organizations to move to BDD. There is again the talk about white box and black box testing which also plays an important role as to whether development teams resolve to TDD or BDD. In deployment pipelines we also have Sonarqube which helps with coverage analysis but component/integration tests are usually black box tests written by QA organizations. TDD or BDD is a very debatable topic and past experience has told me that really depends on what the development/QA (engineering organization) are comfortable with to get latest code to customers asap.

This video goes to the point and super easy to understand.

Nice!!!!

Nice tutorial. So informative.

"Waterfall is like a train" ... bites tongue trying to avoid mentioning SAFe's Release Trains 😀

"Something of an accent left" 😂

Focusing on velocity -> feature factories -> keep shovelling widgets out the door & don't waste time thinking about feedback ☹

big thanks for that series of videos. I realize now that I am doing kanban since ages then. 🙂

My experience is of a team that prioritises items by value, but uses velocity to create a sense of predictability around release dates etc.

w

Good point! In the US we are often more about driving the amount of work completed - Velocity. But Value, as you say here, is much more important. So how to measure value rather than Velocity, or with it, is the real question.

Gotta measure the outcome to make sure the work has value. Or else it becomes a factory just putting out work so people have jobs.

Do not agree on the point that story slicing is easy. 2 reasons: 1. You are assuming that it is already known what the slices might be. Idea of estimates are that you can estimate anything, but you can not always slice everything. Often tickets created on green fields projects can be abstract or contain an element of the unknown. It becomes a problem for short term forecasting. I have this important next epic, by when will it be done? 2. The admin it takes for teams to slice stories are arguably just as long as it may take to estimate them. - "So lets slice this story, lets start identifying what needs to happen. How many components will be touched? Is it something we have done before?" - "Well.. not sure.. first we need to see if we find out.. then we need to do this.. but I would have to come back to you on this.. not sure" Get my point? More tickets and discussions with slicing just moves the effort for the team to understand a story before taking it on from something called "estimates" to "slicing". Is the one then better than the other or not? I'm willing to give #NoEstimates a try and simply blindly pull in a number of stories without slicing. Over time with enough data anything becomes defensible, until the stakeholder asks: "This epic, by when?" then.. again its ooh aahh.. At least in that case a reasonable answer from scrum is possible where a much wider range is possible via #NoEstimates. What is we simply say, rough estimates is good enough, no slicing required. Small, Medium, Large. We map story points onto it and call it a day. At least I will not have the Product Owner prioritizing the backlog, ask the question ANYWAY, since he would like to know when a particular coming item will be done to coordinate with other teams..

Very helpful. Thanks for sharing your knowledge. Have a great weekend. ☕

Very informative video. Thank you so much for sharing your knowledge. Have a great weekend. 👍

dude repeats the video title for 30 seconds straight..

Thank you so much for this lesson. I was so captivated by it. So in summary, for Scrum and Kanban, let fools contend, whichever is properly done is the best option (apologies to Alexander Pope).

I am going to try it and tell you the result in 6 month =)

I have the only question about User Stories that are huge and need to be decomposed. How to deal with it?

The content is awesome and helps a lot, thank you so much.

Very helpful. Thanks for sharing Have a great day. 👍

hey @Development That Pays , great stuff- i'd love for you to talk about the process as a whole (for Kanban). I've been doing scrum(ish) but watched your latest video 𝑯𝒐𝒘 𝒕𝒐 𝑺𝒖𝒑𝒆𝒓𝒄𝒉𝒂𝒓𝒈𝒆 𝒚𝒐𝒖𝒓 𝑨𝒈𝒊𝒍𝒆 𝑩𝒐𝒂𝒓𝒅 (𝑲𝒂𝒏𝒃𝒂𝒏 𝑩𝒐𝒂𝒓𝒅) and you really convinced me to go with Kanban. The concept of a "trigger point" is really useful along with a lot of other things you said.. but back to my request,,, i'm trying to figure out the exact process of how it all comes together for Kanban and how to implement it w/ my weapon of choice Favro (similar to Trello). For example, I'm guessing I would need: 1. Roadmap/Initiatives (timeline view/ sheet view) 2. Release Planning (kanban view) 3. Product Backlog (list view) 4. Work Board (kanban view) 5. Release (kanban - but do i even need this one?) I also have a concept of an "Inbox" collection where things come in from external sources (github/ feature requests from a form/ bugs from a discord channel/ team ideas/ ect). it's kind of like a catch-all would be checked periodically and bring in work to the backlog if it makes sense (originally stole this idea from GTD). but anyways, yeah I guess i'm getting stuck on the exact flow of a card from step 1. to 5. and how everything feeds into everything. it would be cool to see the entire journey, from high level initiative getting broken down to low level completion and handed off [rinse/wash/repeat].

Thanks for the explanation, as well as the attached sheet.

excellent presentation in finest way

Number 5 all the way - maybe even a flag marker (maybe No. 4 - but then u gotta show some context visible even externally so I don't have to open the card to read comments or PRs etc. )

Adding a swim lane (row) above/below is a great idea. I wonder if I can get Azure DevOps to automatically change a card visually when it is moved to "Blocked". Hmm...

Awesome, can you share how to implement this in Jira? Or other tools? Thanks!

Great explanation!!! Thank you.

Very detailed information. Looks good thanks for my free copy.

I've seen codes that looked like the right ladder -- it made riches alright, but that would also mean the ladder will be reused by other clients. These clients needed fine-tuning to the ladder, more features being added. And that quick-and-easy build that provided riches has comeback to bite in the ass because it became unmaintainable. The only way to get more money is to sell that same ladder to new clients which would mean more headaches maintaining that ladder. I say, good luck!

Thanks for this

🎯 Key Takeaways for quick navigation: 00:00 *🛣️ Walking the Board Overview* - Introduction to the concept of "Walking the Board" or "Walking the Wall" in Agile stand-up meetings. - Explanation of the importance of starting stand-up at the top right of the board. - Discussion on the financial and practical reasons for starting at the rightmost side of the board. 01:27 *📊 Stand-Up Progress Review* - Detailed walkthrough of the stand-up process, starting with discussions about specific cards on the board. - Illustration of how team members provide updates on the status of tasks and address any issues or blockers. - Emphasis on the importance of keeping discussions focused and brief during stand-up meetings. 02:48 *🌟 Moments of Glory* - Reflection on the satisfaction of moving cards across the board during stand-up meetings. - Discussion on the significance of allowing team members to move their own cards, adding to their sense of accomplishment. - Exploration of the impact of acknowledging individual achievements and fostering a positive team dynamic. Made with HARPA AI

Fine for development work but companies and trying to squish engineering / support work into this model and it winds up taking more time for spint meetings and jira work than actually getting things done. Hate it. It's micro management for non dev teams.

Good content. The cheat sheet came to mail. Thank you.

But this No Estimate approach requires you to refine the whole 'project' into small User Stories at the start - isn't that waterfall?

Both can be combined but we have to remember something. What is the target of what we are doing? - Put a shelf on the wall? - Store my books? - Or put a nail exactly at the right place? And if I decide to use a screw for the last one? Will that cover my needs? TDD helps the developper to develop. BDD helps the team to satisfy the requirements. With TDD, what happend if the shelf by itself is not perfectly aligned with its own spécifications, and does not match the requirements? TDD is forcing you to add integration tests. If not, at the end, it can not cover the complete target, and you will have to fix the complete system. Using BDD, you will first think about your needs. Maybe two nails will be enough. Then if you have to reach better performances, as the storage of a bigger object, you will be able to add the two extra nails that you need.

Vasco's discovery is not so much a discovery, as it is a result from common statistical principles. As example an average 'storypointet' project would tend to a story point distribution that falls into Pareto (80-20) distribution. A project with too many complicated stories (breaking away from pareto to like a non-pareto 60-40) would in the end be taken into discussion as there are too many stories that are too complicated and need division to manageable pieces. What Vasco's method can encourages is to decomplexify the stories in the start or in the process of the project, aka. we learn as we go.

A brilliant job as usual Gary. You covered all of the salient points. My favourite blocking method is to change the colour of the card but leave it where it is. This works really well with WIP limits because it still counts as WIP even when it is blocked so does not get forgotten about and can be focused on to get the block removed. One amendment I would suggest is don't use "Design Done" or "Development Done" there is only one Done. Use Design Complete and Development Complete that way you don't get the conversation around is it Done? Done Done? or Done Done Done? Reserve Done for it is Done as far as the Team is concerned and either in production or waiting to be released.

That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.

@Developmentthatpays, I noticed the link to the cheatsheets doesn't work! Nice video!

Great video Gary! I like the way you express the idea with animation. Very straightforward! Instead of getting rid of estimating, can we do story-slicing to get better estimations? I think the information of story points is not quite like junk food. It can be helpful in some use cases.

This channel is in every way my cup of tea, thank you!