Comments for AlexHamer.ca

Comment on Breaking down user stories into tasks by alex

alex — Wed, 08 Jun 2011 20:34:31 +0000

Hi Celeste,

It’s hard to offer much advice without knowing more. Reading your post, though, I’m not sure about some things, so to clarify — you want to estimate your stories using story points but not your tasks. Tasks are usually estimated using hours (a good one is fibonacci numbers) or relative sizes (XS, S, M, L, XL).

You may want to try applying some more constraints, in other words don’t have stories that are estimated to be longer that 2-3 days, and aim for tasks that can be completed in a half day or less. This could mean more prep work, depending on the domain and technical knowledge your team has. It also depends on the length of your sprints — are they a week or four weeks or somewhere in between? The longer the sprint the harder this will be.

Another good constraint taken from Scrumban is to limit the number of stories that can be worked on at once (e.g. if you have 15 stories on your board with a team of five, only allow two or three to be worked on at one time). We physically put paper in front of the other stories to remove the distraction.

Good luck!

Comment on Breaking down user stories into tasks by Celeste Dwyer

Celeste Dwyer — Wed, 08 Jun 2011 16:31:38 +0000

We are pretty new to Scrum and are experiencing the same thing. If the stories are too broad, most of our story points only get complete at the end of the sprint and we can’t really see the progress. However, splitting up the points to specific tasks can be very time consuming and not always thorough as the developers discover things as they go. Any advice on finding the ‘middle’ ground would be appreciated!

Comment on Implementing UI Design in Scrum by Jason

Jason — Tue, 02 Mar 2010 16:27:43 +0000

Something else to consider is, if the stories have been broken up into small enough chunks of work, the design of each piece should not take all that long. Developers can usually get going on a piece of functionality with a complete visual design. A down-and-dirty wireframe on the whiteboard will do, in most cases.

One huge benefit of in-sprint design is the organic nature of full team collaboration. I believe doing one-sprint-ahead design falls under the scrummerfall heading. Discussing UI choices with the entire team present goes away when the Dev/QA folks are focused only on implementation and designers are focused on what’s ahead.

Comment on Adding a Second Scrum Team by alex

alex — Mon, 14 Dec 2009 22:30:31 +0000

We’ve actually had some staffing changes since I wrote this, and as a result the two teams only lasted a couple of sprints. What I’ve done is split out the applications architect and the UI guy into their own Scrum team, with the other team now standing at: four programmers, 1.5 QA (one QA shares her time with other projects and steps in when necessary), and one BA. I kept the BA as part of the team because he is playing more of a ScrumMaster role, and as such I need him very close to the team.

Thanks for the comment.

Comment on Adding a Second Scrum Team by Craig Brown

Craig Brown — Mon, 14 Dec 2009 22:25:23 +0000

I’d be inclined to split the BA and UI person onto the two separate teams and get them to share their roles.

That way everyone is mainly focused on their local team goals. You are also heading towards breaking down some specialisation/building in redundancy/broadening the team’s skill base/ etc

Comment on Scrum: A Year in Review by Craig Brown

Craig Brown — Mon, 14 Dec 2009 06:47:57 +0000

Alex we have had a very similar year!

Comment on Adding a Second Scrum Team by alex

alex — Fri, 11 Sep 2009 16:52:20 +0000

That’s exactly what I’ve done. We’ve run two sprints with the two extra staff working with the first team. Starting the next sprint we *will* be adding a QA at the same time we’re splitting the teams, but I don’t think it should be that big of a deal — they’ve all worked together before.

I’ll write a follow-up post in a few sprints … I hope this works!

Comment on Adding a Second Scrum Team by Kevin E. Schlabach

Kevin E. Schlabach — Fri, 11 Sep 2009 14:12:20 +0000

Because I’ve seen larger scrum teams, I would suggest adding the new resources to the existing team. Let them run a sprint or two together and build some chemistry. Then split the group into two small teams.

When two scrum teams are working on similar stuff, it’s important for the scrum of scrums to go smoothly. By focusing on team chemistry first, you can diminish the us/them cross-team problems that might occur. I’m writing this from a negative standpoint, but I really intend it to be a pro-active/positive idea.

Good luck, let us know how it worked out!

Comment on Promoting Quality in Scrum by alex

alex — Wed, 29 Jul 2009 16:00:13 +0000

Fair enough. I’ve already started reading their blogs — thanks for passing their names along. I’ll pass them along to my team as well.

I won’t be making it to the agile 2009 conference, although I’ll do my best to get to the Agile Vancouver conference … a little closer and easier to manage.

Cheers!

Comment on Promoting Quality in Scrum by Kevin E. Schlabach

Kevin E. Schlabach — Wed, 29 Jul 2009 15:52:25 +0000

I wasn’t necessarily suggesting paying for a coach as much as introducing yourself to them and building a relationship. That might be through their work, blogs, etc… or by the people that surround them and picking their brains. With the Agile 2009 conference coming up, it’s a great opportunity to network!

I find that many of these people (myself included) will interact and provide a certain amount of dialogue for free knowing that good relationships don’t start with an invoice!

; )