Tag: Sprint

Categories
Agile

Agile: Group Technical Review Worth It?

Every since I started practicing agile development and processes, I have lobbied for some type of group tech review before release. At the end of the sprint, the tech team (devs) get together and everyone can go over what they did, give some insight to what they did and why and everyone else can get a glimpse into the other work that was done. Tech reviews aren’t meant to beat anyone down, but they shouldn’t waste everyones time either. I think developers need to get that interaction as well as learning how to show what they did to their peers. Thoughts?

For the most part this idea of a sprintly tech review has worked well, but in others it breaks down.

Why? For one it takes time. If you are so crunched at the end of a sprint, then who has time to do a tech review? In some teams, this hasn’t been an issue, maybe it was better planning or estimating, or maybe just dumb luck, but doing the review made it into the sprint.

Maybe on some teams doing mini reviews with the group throughout the sprint instead of all at the end is the way to go. Maybe not doing any review at all.

My head is still with doing a group review at the end. I think the estimation and wrapping up at the end of a sprint probably would need to get looked at from a process perspective. What can be automated? I’m sure more than maybe you are doing now, etc.

I for one welcome new ways of doing things, but more efficient and still get the points across that need to be. Bring on the ideas – let me know your thoughts in the comments.

Categories
Agile

Agile: Epics

So most people are familiar with “projects”. Something you do, have an end goal, usually a budget, resources, plan, etc. Sometimes you have projects within projects. Like a good example may be thinking of the next version of Microsoft Windows as the main project and revamping solitaire for the next version as the “epic”. Your end goal is to keep your main project moving forward, and do stories that apply to that project, but you also might run into mini projects along the way that could cross over numerous sprints, and you want to “group” like/similar stories together to form an “epic”.

What is nice about epics is they still let you do your sprints, and stories as normal,but you have a more higher reaching goal to get a set of stories complete to complete your epic. It also lets you look back and then see how many stories and points you did toward that epic and understand the effort,etc that went to completing it.

Use epics to group stories together to form a common goal for a similar “thing”. It will let you say “let’s focus on the blah epic” and you can make sure you get that piece of functionality done and track it and see all those stories together in the end.

P.S. Blogged from my iPad

Categories
Agile

Agile: Retrospective

The retrospective. The cousin of the “postmortem”. Why not a postmortem? Because our project didn’t die. We want to reflect on what we did right, wrong, how we can improve, what did we learn.

What is the retrospective? I like to have a 15-20 minute section before “review” and “planning” in the Sprint Planning Meeting. Everyone goes around and says what can we do better? What did we do bad? What did I learn? Capture the thoughts and feelings of people and look back at the last retrospective and see what you did this sprint to improve on last sprint.

The hardest part of this “retro” seems to be 2 things, depending on team. Some teams find all the *bad* things and list them out. Some just find all the *good* things and list them out. You need to have a balance. Some things always go better, some worse, so put them out on the table.

If you don’t know where you came from, you don’t know where you are now, or where you are going.

Categories
Agile

Agile: Sprint

The sprint. The timeline of an agile team. The sprint is the “timebox” that you use to get your stuff done. It’s an iteration as you want to keep having sprints over and over.

You might have many sprints make up a release, you might have one sprint make up a release.

Your sprint could be a number of different timeframes.

I suggest 2 weeks.

Why 2 weeks? Well, it is enough time to get things done, but not have too much to worry about, it also ensures that things you want to get done are done in a small enough time frame so that the people that needs to see your outputs don’t have to wait longer than 2 weeks. 2 weeks also fits nice as 4 weeks could almost be considered 1 month.

Other alternatives? 3 weeks – might be the only other time frame I would suggest using, but then remember, if you have something get requested before a sprint, and you can’t get it into the current sprint, you won’t see that story completed for 6 weeks!

1 week is too short, you are just constantly churning. 4 weeks is another one that some teams use, but again, it could be 8 weeks before seeing something. The world just moves to fast for that kind of timeline.

Other options are doing staggered sprints. 2 2 3 2 2, or 2 3 2 3 2, etc. It can get confusing, but doable, I haven’t seen a reason to do it yet, so I have kept to the 2 week timebox.

I also recommend starting on a Tuesday, Wednesday, or Thursday. If you run your sprints say, from Tuesday, 2 weeks, you end up ending on a Tuesday afternoon. Same with Wed/Thurs. And you can do your Sprint Planning on that Tuesday/Wednesday/Thursday. When you use Friday and Monday, things just get tough to plan around. You probably never want to release on a Friday, people like to take vacations and days off on Fridays, tec.

Another tip, don’t treat a sprint like a mini-waterfall project. You will end up in trouble. Try to test/validate completed stories as they get completed by the do’ers. Waiting until the end of a sprint will lead to pile up of things to do.

Throughout the sprint, the product owners and requester of features should be in the loop (for one, with the Daily standup) but also they should be seeing the fruits of your do’ers labor, they should be seeing the output and features as they are completed.

Releasing at the end of the sprint is key. If you can’t, then you should at least have things in a “potentially shippable” state so you can demo and test it for the people that have requested it.

Other things you can do with your sprints. I like to separate out things into their own “mini sprint” when needed. An example might be, Upgrading your infrastructure to SQL Server 2008. You can’t really work on things on your servers when they are being upgraded, so at the end of a sprint, say “the next week is a mini sprint for the upgrade” and then pick up your regular sprint schedule after that. Same thing with holidays. Over the Christmas and New Year holiday you may have a 2 week holiday sprint. Just let your do’ers do research or something fun they have wanted to do. Most people will be out of vacation anyways.

Treat your sprint though like you would treat your daily standup. You don’t (you really can’t – or it screws up things) want to keep adjusting your days and length very often. The more you adjust the more it confuses people and the harder it is to try to get your actual velocity.

Pick a date to start, pick a timeframe, and stick with it. Try to stick with it for a year, at least 6 months before totally changing things up. Discipline, just like the daily 15 minute standups. Keeping things standardized and set helps your team and others know the schedule and keep things on track.


Categories
Agile

Agile: Backlog

The product backlog. Not a ton to say on this right now, but here are some thoughts.

  • The current sprint is not backlog
    Seem’s obvious. But the backlog is the backlog. The current is sprint is what you are focused on and working on.
  • The next sprint is backlog
    yes, the next sprint, on your board, is still backlog. It is somewhat solidified, but it is in flux until when you start the next sprint as your current sprint.
  • Your backlog should be semi-full
    having nothing in your backlog means.. well, you have no backlog, and that isn’t good. You should have enough stories for 1-2 sprints. Having no backlog is like living paycheck to paycheck.
  • You should prune old stories
    Older stories that have been just living in your backlog, should get pruned. Either they are higher priority and should get done, or they aren’t worth doing. They might resurface later as something but they shouldn’t be carried along for months/years if they aren’t important enough to do.
  • Priority matters
    The product owner should make sure they have the backlog prioritized. An backlog that isn’t prioritized is just a stack of cards.
  • Split Backlog into buckets
    I like to split backlog into buckets. Technical vs Product, maybe Features vs Bugs, some way to differentiate things.
  • Try to get as much as you can scored
    You might want to try to score as many stories in the backlog as you can so you are always ready. Of course there is a balance. You want a full backlog, you don’t want 5000 items, and you don’t want to take 3 days scoring things. Score enough so that if you do get ahead you can take stories from the backlog to work on. Try to avoid scoring outside of sprint planning sessions.

The backlog is one of the most important parts of your Agile process. Without a backlog you don’t have anything to focus on as you move forward through iterations. Try to think of it as a well, a well you don’t want to dry up, but you don’t want to overflow either.

My preference is to have a product backlog and technical backlog. That ensures that technical debt isn’t ignored, but separates concerns as far as features that you might want to implement.