Agile Nerds Please

leaskovski

leaskovski

leaskovski

Soldato
Joined
22 Oct 2004
Posts
9,086
Location
Berkland
This might not actually be good for GD, maybe it should go in HTML, GFX & Prog?

Ok, so I have a basic understanding of Agile, and the idea of Epics, Stories and Tasks.

In an ideal world, you would have a product backlog, and every new feature request would be dumped in there and sprints would be built off of that. Unfortunately, our concept is that features are grouped together into a project and that project has its own backlog. The powers that be, always want some sort of idea how big a project is going to be resource wise.

So, when we start our project, we are effectively creating stories for the epics in the project backlog and coming up with story points and acceptance criteria. Those points are based off of effort, risk and difficulty. A good way of doing this is playing story point poker with the team.

Once you have got all that nailed, I have always thought from that information you can roughly come up with an idea of how many sprints you will need to cover all those stories and roughly how long those sprints should last for, thus giving you a rough idea of how long that project will take knowing that at the end of those sprints, epics that don't have a complete set of stories against it in the form of completed tasks, don't make the cut for the project.

So my hang up with the above, is that the relation of story points to how many of those you plan to cram into a sprint and the size of the sprint for that cramming.

I know the above is not really Agile, but some horrible ginger step child, but I would appreciate if anyone else out there that does anything similar to the above has any comments on how they make the jump from Story Points to Sprint Size.

Awaits the "You're doing it wrong!"

Ta
 
SuperStock_1589R-40351.jpg
 
I thought agile lifecycles were used for projects with changing requirements?
If you plan out exactly what each of your 'sprints' contain with timescales and deliverables for each one, then it's more of an interative waterfall pattern than a real agile lifecycle?
 
This needs to be in programming to get serious answers, but I'll give one a go.

leaskovski said:
The powers that be, always want some sort of idea how big a project is going to be resource wise.
Click to expand...

This is why pure agile is rarely implemented.

It requires an understanding and trust in the process that isn't common amongst senior management.

Imo, the biggest problem isn't resource, as agile teams should be small. It's estimated time to deliver a viable product i.e. they must know when they are going to get all of their shiny new thing.

This is especially true for greenfield projects, where a single sprint doesn't offer a sufficient event horizon for management to feel comfortable. What they don't realised, is hard long term estimates are often just made up, and this is why waterfall projects are invariably late. Cake and eat it springs to mind.

The answer is.. employ expensive agile consultants to explain they're doing it wrong. Management only speak money, and when it's costing, they tend to listen.
 
Last edited:
Stretch said:
This is why pure agile is rarely implemented.

It requires an understanding and trust in the process that isn't common amongst senior management.

Imo, the biggest problem isn't resource (as agile teams should be small), it's estimated time to complete a viable product i.e. when are they going to get all of their shiny new thing.

This is especially true for greenfield projects, where a single sprint doesn't offer a sufficient event horizon for management to feel comfortable. What they don't realised, is hard long term estimates are often just made up, and this is why waterfall projects are invariably late. Cake and eat it springs to mind.

The answer is.. employ expensive agile consultants to explain they're doing it wrong. Management only speak money, and when it's costing, they tend to listen.
Click to expand...

Now that's a thought. Though getting that signed off would be a hilarious episode!

touch said:
I thought agile lifecycles were used for projects with changing requirements?
If you plan out exactly what each of your 'sprints' contain with timescales and deliverables for each one, then it's more of an interative waterfall pattern than a real agile lifecycle?
Click to expand...

the changing requirements in this case is the ever evolving feature. The epic is usually fairly loose and allows the team to expand the feature out into a better feature to fit the product much better than the original idea. The basic premise of our process is that we are effectively using the agile name to try and shorten the up front planning that you have with waterfall, which we end up wasting too much time on. The term agile is banded about, but that isn't what we are doing.

I guess our best bet is to look at the stories and their points and then come up with some sort of multiplier to try to apply to the points to come up with a rough number of days that we feel is happy for the stories in question and apply that to entire project. That in theory should kind of aid in the guessing game.
 
Last edited:
LOL! Just had a meeting and all this was explained to me - Planning Poker, that numbering/points system that can be used (1,2,3,5,8,13 etc), Vertical slicing etc :D

Okay, so what was explained to me was once we have all the tickets/tasks numbered up, in the first sprint (lets say a week) we will do as much as possible - maybe covering and clearing 10 points - so from there we will be able to start estimating the project time, as we know it took us a week...so on and so forth...

The sprint week (for example) will have a planning meeting at the start of the week, a planning 2 (or a grooming) meeting half way through the week (where necessary) and a retro at the end of the week where the productivity can be discussed and look at any issues which could be possible blockers moving forward...

So, the number of Story points to be done in a week is built up over time. Unless you are a team which has been doing agile this way for a while and you already know your estimates are accurate...thats how we are going to do this next project :D
 
TrixiBuG said:
LOL! Just had a meeting and all this was explained to me - Planning Poker, that numbering/points system that can be used (1,2,3,5,8,13 etc), Vertical slicing etc :D

Okay, so what was explained to me was once we have all the tickets/tasks numbered up, in the first sprint (lets say a week) we will do as much as possible - maybe covering and clearing 10 points - so from there we will be able to start estimating the project time, as we know it took us a week...so on and so forth...

The sprint week (for example) will have a planning meeting at the start of the week, a planning 2 (or a grooming) meeting half way through the week (where necessary) and a retro at the end of the week where the productivity can be discussed and look at any issues which could be possible blockers moving forward...

So, the number of Story points to be done in a week is built up over time. Unless you are a team which has been doing agile this way for a while and you already know your estimates are accurate...thats how we are going to do this next project :D
Click to expand...
Argm, forum error! lost my reply. GRRR!

Anyway, yeah, that's right. You should take the velocity from the burn down chart and use that to aid in selecting what stories to take into the next sprint based on the sprint size, velocity and story points.

It would be interesting to see if velocity works out about the same over a series of projects. It probably won't though, which makes the initial estimate on project length hard.
 
leaskovski said:
Argm, forum error! lost my reply. GRRR!

Anyway, yeah, that's right. You should take the velocity from the burn down chart and use that to aid in selecting what stories to take into the next sprint based on the sprint size, velocity and story points.

It would be interesting to see if velocity works out about the same over a series of projects. It probably won't though, which makes the initial estimate on project length hard.
Click to expand...

We have 3 big projects coming up in the next few weeks and I believe we are going to use this technique (Its new to me and I am lead tester on all of them :eek:) So I can probably let you know :)
 
Agile is a framework though. You don't need to implement every aspect of what doesn't make sense if your business. Offering key pieces of functionality, or something useable per sprint to the user / customer is the ideal, but then your sprints don't HAVE to be 2 weeks.

You don't have to do scrum, kanban etc. to the nose, it's taking agile as what it is, a set of tools to help you make sense of your work and better manage changing projects in manageable chunks.

EDIT: I'm in the process of studying for my PMI ACP.
 
You must log in or register to reply here.
Back
Top Bottom