Agile Nerds Please

[leaskovski]

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

 

[leaskovski]

I knew that was coming... Not that exact picture, but something similar.

 

[leaskovski]

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.

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

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?

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.

 

[leaskovski]

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

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

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]

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.

Woooh, we have a bad ass in here.

Brilliant. So being that you are some sort of guru on it, and I have laid out in my OP how we have taken some parts of the agile framework and "waterfalled" it... any advice?

 

[leaskovski]

The Epic should outline "loosely" (like you said) the problem that exists.

The storyboards or points relate to the features and functionality that are required.

This is not how you will do it but the top level of what is wanted. It shouldn't be solutionized at this stage. You can then put a weighting (sometimes done with points, or poker cards etc. which I have a set of on my desk, unused, or just prioritized with the stakeholder/proj sponsor).

You then set the length of your sprints to what makes sense, but the idea of them being 2-4 weeks is not so that it can always change requirements, but you get something to the customer as quickly as possible, but also receive feedback as quickly as possible. If something has changed it can be brought up in a much more timely fashion than in a waterfall type approach.

Thats all I wanted to hear. You have kind of answered my question there.

Thanks a million! I owe you a pint.

 

[leaskovski]

Very interesting this - I've been trying to reconcile the PRINCE2 and Agile methodolgies, and have come to the conclusion that they sit together like oil and water.....

From what I can gather, most businesses think that Agile means you can make it up as you go along without writing any requirements down.

Yeah, that can be a bit of a pain. Our processes wrap around the 'agile' stuff that we have, so we won't even get to 'sprint 0' without some sort of documented requirement. The requirement comes in, in paper!! Then I sit down with the other senior guys and come up with an outline of a solution, very high level stuff that we know fits in to the product. We give some wild estimates, then its decided if its worth doing based on the wild estimates. If it is, we then Create the epics based off of that high level requirement/solution. Then its sprint 0, story and acceptance criteria time.

Being that we have an audit every year, if there wasn't anything recorded, we would fail, so it has to be done really.

 

[leaskovski]

If your product has a roadmap, how does the business decide if a project is worth doing if the effort is unknown and how is it able to build a roadmap if it doesn't know when things are to be delivered?

The reason we do our up front estimate before it even goes near our dev teams is for that purpose.

 

[leaskovski]

Thanks everyone for your input, it has been very helpful!

See GD can be of use.