@jhanggi:disqus first of all, thank you for the comments! 🙂

I really liked those practices you are using at Table XI!

It’s very nice to see how other companies evolves their practices. We use something similar with your “Story Time” here. Few days before our planning meetings we do a “Grooming” meeting, to clarify what the stories really means and put all the team on the same page. It makes the planning meetings more smooth and fast!! I’m really glad to know that at Table XI you are doing this too.

I’ve never tried this standup practice, but it seems to be very valuable since it gives focus to the work in progress instead of the traditional “daily report”. I’ll suggest this in my current project and maybe write another post about how it goes.

Something that’s been incredibly valuable for us regarding “continuous integration” is that many of our projects are set up to have our CI server run on all pull requests. We no longer commit directly to master (we actually use a `develop` branch–that’s what on our staging server, `master` is what’s on production). Everything goes through a PR. That way, we know that everything should work just fine once we merge it in.

We’ll often use Work in Progress (WIP) PRs for longer running or more complicated features. We’ll still use feature flags when necessary, but if the feature really is big enough to warrant it, usually the overhead and effort of implementing the flag–and eventually removing it–becomes small enough within the context of the feature.

One of the things within projects that we’ve recently introduced at Table XI is affectionately named “Story Time”. All the devs on the project get together in a room and go through a few of the in progress and upcoming stories. We go through and discuss the story, make sure everyone understands what the story means, and develop a plan of attack. Sometimes it’s as simple as reading the story, and everyone saying “yes, we all agree on what this means”. Sometimes it goes into deeper discussion and we make known the unknowns and risks within the story. We don’t start on any story that hasn’t been story timed recently. This is especially valuable for stories that were written a while ago and are possibly ambiguous or vague.

On my current project we often roll this up into our standups, so it’s much more of “What is the status of this story” vs the traditional “What am I working on today”. It also allows us to say that a story is no longer valid, doesn’t provide sufficient value vs amount of effort, needs additional analysis, or requires feedback from the client. These are things that could be part of the traditional IPM, but is much more focused on the actual implementation details.