Agile Nerds Please

DRZ said:
You need an extremely good scrum master to get between the team and the product owner.

If you don't have that you can bin the whole lot because the planning becomes worthless as the PO just demands whatever he wants at that time.
Click to expand...

Depends on your PO. I sit as PO and have a BA and a Senior Dev. I structure stories with the BA and attend pre-planning where I go through the stories with the team. I use cucumber for acceptance criteria. I'll get a rough idea of the sprint output at that point and split stories or substitute for spikes as required. The team then do their poker planning without me and tell me what the output of the sprint will be.

Agile works when the business and IT work together and there is no point in trying to force through extra functionality as it just leads to errors and rework.

I've been in the position if being asked to estimate everything up front before as vague stories and it's was a waste if everyone's time. One of the drivers for Agile is that estimation like that is almost always wrong.

I have, however, worked in a project to develop a gambling algorithm where the full behaviour was documented using BDD beforehand resulting in a series of tasks if complexity 1 do each could easily estimate. That meant all the Devs and Testers stepping away from their keyboards for two whole weeks so I doubt I'll ever get the chance to do it again.
 
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.
 
Finger in the air estimates get you started. Those estimates will be just as valid as anything you spend time over. If it looks like the business case then commit resources. Once you have a few sprints under your belt you can then compare your progress against your business case estimates and see if you are likely to achieve what you set out to do on time or budget.

Generally requirements change over time so projects generally never deliver on time or budget. I've worked projects where the business case took longer than the development. By the time it was complete the environment had changed sufficiently to render many if the assumptions invalid.

I prefer finger in the air and then fix budget allowing time and scope to flex. Staged funding allows you to ditch the product at relatively short notice. I'd rather ditch a product that looks like it's going to be a failure before a delayed launch date and divert the funds onto a more promising product.
 
leaskovski said:
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.
Click to expand...

First of all, your projects sound very waterfall-y to me. To do Agile you (and your management) want to be thinking about adding value incrementally, not big one-off projects all the time, with big up-front, signed-off designs (on paper :eek:)!

That way there's far less wasted time and effort spent going in the wrong direction, even if you don't know what the right direction is before you start.

As others have said, if your management isn't on message, then it's going to be an up-hill battle. It may be possible, but it will take time and effort from everyone who has bought into Agile in your company to persuade them of the merits.

You sound like you're more of a software architect than a developer? FWIW, in my company, the architects and the product management collaborate to continually develop a rolling roadmap. The roadmap (which is presented to the developers who will be doing the work, as well as the high-ups) lays out in detail what we plan to do for the next 3 months, then in somewhat less detail for the next 3-6 months. Anything further out than that is noted as high-level aspirations only. The roadmap is updated every couple of months.

This is fairly new to us (and arguably unproven), as some of our PMs and architects have taken a while to embrace agile, but theoretically, it allows us to concentrate on what we know we need to do right now, and to stop trying to predict the future - which you can put an awful lot of time and money into trying to do, but ultimately not succeeding
 
A caveat to start with: I'm an (expired) CSM but to be honest I don't think I've ever worked on a truly agile project or had a lot of experience with this.

My understanding is basically you need to figure out your velocity, which will then let you plan your projects. So in other words use empirical data from previous work/projects/sprints to determine the effective 'weighting' i.e. what story points translate to in terms of effort required.

When you are first starting off, I don't have a good answer as to how to determine this, so here are some suggestions:
-Take some stories of varying point sizes that are similar to something your team has done in the past, if possible, and look at how much effort they took. It's important to do this with multiple stories to reduce the impact of a rogue estimate (or poor choice to compare with)
-Monitor very closely in the early stages to get a sense for how much work is being completed. Maybe even use shorter sprints to start with. It's likely that velocity may improve over time so early sprints can be a fairly safe estimate
-That said, make sure what people say is done is done-done. Early in a project it is quite easy/tempting for people to mark something as done but does it meet the Definition of Done? Even then, is the DoD accurate or will it just be leaving a time bomb for future sprints (e.g. configuration work required, documentation etc).

To address one of the above points, based on my experiences it is a lot harder to move away from the 'big projects'/BDUF with some sort of agreed scope towards 'incremental value' if you are operating as a supplier rather than simply building products internally. Rightly or wrongly, a lot of clients feel they need some degree of certainty (or rather, commitment) about will be delivered when in order for a project to even get off the ground. I think that is why some organisations end up with hybrid approaches whereby although there is incremental delivery, flexible sprint scope etc, there are also some high level signed off requirements that need to be agreed very early on, and also set delivery timescales (which in turn means a management push for estimates, and consequently some initial design work...)
 
Last edited:
the idea is after a couple of sprints you understand the teams velocity (how many points are achievable per sprint), from this you further revise your forward plans.

Sprint 0 should always be your planning sprint, and each story within the epic should be a self contained deliverable. Works wells if used with TDD/BDD techniques

And a key principle is you must not take any points from a story until it's complete, this means some sprints will show as underachieving, but the follow on should over achieve if you have to keep to plan
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom