Agile Nerds Please

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.
 
randomshenans said:
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.
Click to expand...
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? :D
 
randomshenans said:
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.
Click to expand...
Thats all I wanted to hear. You have kind of answered my question there.

Thanks a million! I owe you a pint.
 
So you do pretty much what I do...

EPIC > User Story > Task (where you set your estimates of how you will achieve the functionality of the user story and the time taken to achieve that and whether there are any dependencies. You will more than likely have more than one task set for every user story)
Key there is the prioritization of the order in which you deliver the functionality and what the dependencies are. i.e. you're building a "site" which will have X number of functionalities within it. Your first sprint will have the site as the top, as the rest of the tasks/ stories are dependent on the creation of it. Also known as blockers. These tend to help flush out most of what you deliver first, but key is working with the stakeholder above and outside of the dependencies (as you can't change those) to see what they prioritize functionality wise.

It depends on the project though, so it's not always black and white and not always the same. Sometimes you will be able to do all the user stories at once, but still have dependencies on the tasks / blockers, so this is when priority from the stakeholder is more important.

Also, being agile you can be blocked on something that is outside your control, which is why you would have daily standup to talk over any blockers you have, what you can do to get around them (can be outside of your team/ control e.g. environmental/infra), and always shift tasks around and move other things up your sprint.

Like I said, it's a framework. You can sculpt it to make sense to you really. *******isation is what I do as many of our US folk see it as "time not spent doing" when really it's to make sure time is spent wisely and not wasted/ lost.
 
leaskovski said:
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
Click to expand...

1. Can't you make the Epic your Project Encapsulator? And then have sub-Epics within the main Project Epic?

2. With regard to relating Story Points to Sprint Size, you need a relative variable in my opinion - which Scrum fortunately provides - the VELOCITY. Link: http://www.scrumalliance.org/community/articles/2013/2013-april/how-should-we-use-velocity
 
Last edited:
We use sprints, stands and other words I don't understand in our daily meeting (Actually, I think the daily meeting is called a stand?), but given that everyone seems to have a different form of AGILE in place, potato.
 
leaskovski said:
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.
Click to expand...

The concept you're looking for is the "sprint velocity". This is a historical average of the number of story points you have completed in previous sprints. If you know how many story points you can typically do, then that's how many story points you can plan to do. We do a rolling 3-sprint average.

Based on my experience:
  • This means that the first few estimates will be WAG's until you have some historical information. This is normal!
  • Consistent length sprints are a must or the historical story point numbers mean naff all.
  • You can 'pro-rata' your velocity. So if your historical velocity is 100, but half the developers are on holiday for the next sprint, you can plan for 50.
  • If there's consistently high noise levels, where devs are taken away from sprint tasks, you may only plan for 80% (say) of your historical velocity
 
Of course you need to know what the project team is physically capable in the time period of a sprint which will help you work out how much you can do but not what is covered in the sprint. I don't like scrum for some parts (the roles involved and all that) but take parts from it that make sense.
 
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.
 
nightwish said:
The concept you're looking for is the "sprint velocity". This is a historical average of the number of story points you have completed in previous sprints. If you know how many story points you can typically do, then that's how many story points you can plan to do. We do a rolling 3-sprint average.

Based on my experience:
  • This means that the first few estimates will be WAG's until you have some historical information. This is normal!
  • Consistent length sprints are a must or the historical story point numbers mean naff all.
  • You can 'pro-rata' your velocity. So if your historical velocity is 100, but half the developers are on holiday for the next sprint, you can plan for 50.
  • If there's consistently high noise levels, where devs are taken away from sprint tasks, you may only plan for 80% (say) of your historical velocity
Click to expand...

That's why your stand up meetings are important to find out what was achieved/not if you don't have your historical data on what estimates you have given. But yar
 
matsquatch said:
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.
Click to expand...

You have the types that think you need no documentation of plans, and those that think it's still too much structure... well, in my business you do. :confused:
 
matsquatch said:
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.
Click to expand...
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 said:
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...

I'm not certain what the "correct" answer is here, but we orientate our planning around teams, not projects. Then there's continuity between projects. (It's also important to keep the team stable, rather than moving developers around willy nilly depending on what the priority de jour happens to be.)

randomshenans said:
That's why your stand up meetings are important to find out what was achieved/not if you don't have your historical data on what estimates you have given. But yar
Click to expand...

I guess so, but standups continue to have value beyond the very first few sprints...
 
Last edited:
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.

Estimation of complexity is the second most important thing, alongside fixed sprint lengths. Nobody is very good at everything though so you get people wanting to estimate based on their skill rather than the average skill on the team - tricky because the idea is that anyone can pick up any task...

If the management above whoever is in charge of the sprint team don't get it then you're doomed.
 
matsquatch said:
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.
Click to expand...

Have a look at DSDM - This can be integrated pretty easily with PRINCE2.

It gives a bit more structure and project governance but it's about delivering using agile techniques.
 
I've got a fair amount of experience with Agile/Kanban/Scrum/XP.. here's my 2p...

To me, it feels like a formalised way for people to behave like human beings and actually communicate to each other.

For example...

You're working on Project X and implementing feature Y ... the business owner Dave (who sits next to you) knows EXACTLY what he wants... you sit with Dave and extract requirements and then you begin your coding. After a couple of hours/days, you have some more questions so you turn to Dave and ask for him to come and look at what you've done so far.

Upon seeing your work Dave says "oh blimey.. I can see that I thought that's what I wanted but now I see it in action that's silly! Let's change it!" ... repeat.

Put that in the Agile way..

Dave writes down his backlog (the high level requirements)
You all talk about the requirements with Dave in a planning sessions
You all pick up a task and work on it (maybe in a scrum)
You talk to Dave when you have problems (again, scrum)
Dave changes some things as he gets *feedback*
Repeat.

The things I find have already been mentioned but hey..

1) You categorically, unequivocally must have a product owner with sufficient company 'muscle' in on the ground floor
2) Everyone must talk to the product owner as much as possible and preferably all sit together. The teams that are the best I've seen are desks of 4,5 or 6 and are commonly 1 Product owner, 1 tester, 3/4 devs, 1 dev or dev op (someone who can do DB/environments etc)

that's it.
The 'Agile' tag is (for me at least) a formality put in place because project managers and business people can't accept that things can't be measured, timed and costed. Despite most of them having seen estimates be consistently wrong EVERY SINGLE time they've done them before.

I could go on for ages about this...

Common things I've seen agile teams do is do little to no prep work, e.g. prudent tech. choices (which DB tech to use or language is most appropriate to the task), no architectural overview and good practice, no source control/continuos integration/build environments etc. I've seen people do things called "Sprint Zero" where you do all the planning / architecture and discovery... I'd advocate that!
 
[Slip];25630002 said:
The 'Agile' tag is (for me at least) a formality put in place because project managers and business people can't accept that things can't be measured, timed and costed. Despite most of them having seen estimates be consistently wrong EVERY SINGLE time they've done them before.

I could go on for ages about this...
Click to expand...

I'm sorry but that is simply not true. Work absolutely can be estimated, measured and costed and hopefully you understand the reason this needs to be done.

Yes of course there's risks associated with estimates and that is what the PM needs to manage and there's many ways of dealing with it.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom