Agile Support Helping You Get Better at Agile

I learned a lot today. The material covered today filled in a few huge holes of stuff I sorta knew from reading blogs/books, but this really drove it home.

My biggest takeaway today was estimating and finally 'getting' why time isn't tracked. I didn't even know about 'planning velocity' vs 'commitment velocity' and that helped tremendously with some of the problems I've encountered.

In my organization, we PUSH the work into a sprint instead of the team agreeing to committing to work from the backlog. We end up wasting time 'pointing' the backlog items that were 'put into' the sprint which is completely bass-ackwards. That simple lesson, the charts and formulas Mishkin provided are very valuable tools that will help me right-the-ship, so to speak.

Again, my organization was using 'scrum' before I started there and we don't have any bureaucracy in our company so adoption isn't really an issue, it's really the implementation that hasn't been perfected yet. I put 'Scrum' in parenthesis because we *claim* to be using Scrum when we're really not. We're using some stuff from Scrum, some stuff from XP and some just plain chaotic stuff, which is common to a startup.

What we are doing wrong:
- the Product Owner (PO) and ScrumMaster (SM) are defining the sprint goals and the backlog items that will be done in the sprint. anything not done just gets moved into the next sprint.
- the estimating of backlog items was done on Day 1 of the Sprint so the team pointed out effort for our stories.
- the task breakout happened after the sprint planning meeting and often throughout the week when a new story was taken.
- we are not making a distinction between planning velocity and commitment velocity (we were using the planning velocity as our velocity, period.)

What we are doing well:
- we estimate our stories very well. There is not usually a big discrepancy between the points estimated for backlog items.
- we define done fairly well. Given the small team and nature of our business we have the luxury of being able to quantify 'done' pretty easily. There are times when it's tough, but for the most part.

Above all else, the product owner, stakeholder and scrum master are sometimes the same person (which is me) and the other times, the stakeholder and product owner are also the same person (our CTO). The problem is, our CTO is very technical so when it's time to estimate, he often jumps in to tell the team a better way of doing something.

He means well, but 2 problems happen:

1) the team relies on being told what to do and how to do it
2) there is no sense of trust

I think these are easy problems to fix given our environment and provided I see some folks come back to this site, I'll keep on updating!