One for the Agile gurus
Discussion
My large organisation is introducing 'Agile' in a pretty haphazard manner. It is being driven by IT alone, when any basic Agile course tells you that you need business buy-in, engaged Product Owners in the business etc.
That aside, we are also (again, in my opinion, haphazardly) applying this across the board, from cutting edge apps to 40yr old legacy mainframe systems - my area. Again, a lot of Agile theory says you don't apply it to your monoliths, but we've been told that it has to apply to everything.
The biggest problem I am having is the absolute terrible quality of User Stories; the people tasked with writing them don't really know what they are doing, and as an IT department we have no clear 'Definition of Ready' for taking something into a Sprint. As you can imagine, despite expecting to be on a steep learning curve, it all seems a bit of a disaster before we have even got going.
Which leads me onto my main question: where in the Agile world do you do what is the traditional 'Analysis and Design' for each User Story?
My interpetation is that this is during Sprint Refinement - you look at those vague stories that are approaching the top of the backlog and work out within the team exactly what needs to be done, flesh out the detail, so that you know that by the time you want to to take the Story into the Sprint the programmer should have all the requirements in the Story and all analysis done, in order for them to start productive coding on Day 1 of the Sprint.
What we are getting it a vague set of requirements in a Story, it being thrown into a three week Sprint, and techies like me saying "hang on, this needs several days' analysis before I even know where to start coding". Much frustration all round from people who are used to being given a spec and being told "code this".
Please tell me I'm not going mad? I understand we should be looking at small, iterative changes, but these have got to be scoped out, and this should be done, as far as I understand, during Sprint Refinement. Currently we have zero time devoted to this process.
That aside, we are also (again, in my opinion, haphazardly) applying this across the board, from cutting edge apps to 40yr old legacy mainframe systems - my area. Again, a lot of Agile theory says you don't apply it to your monoliths, but we've been told that it has to apply to everything.
The biggest problem I am having is the absolute terrible quality of User Stories; the people tasked with writing them don't really know what they are doing, and as an IT department we have no clear 'Definition of Ready' for taking something into a Sprint. As you can imagine, despite expecting to be on a steep learning curve, it all seems a bit of a disaster before we have even got going.
Which leads me onto my main question: where in the Agile world do you do what is the traditional 'Analysis and Design' for each User Story?
My interpetation is that this is during Sprint Refinement - you look at those vague stories that are approaching the top of the backlog and work out within the team exactly what needs to be done, flesh out the detail, so that you know that by the time you want to to take the Story into the Sprint the programmer should have all the requirements in the Story and all analysis done, in order for them to start productive coding on Day 1 of the Sprint.
What we are getting it a vague set of requirements in a Story, it being thrown into a three week Sprint, and techies like me saying "hang on, this needs several days' analysis before I even know where to start coding". Much frustration all round from people who are used to being given a spec and being told "code this".
Please tell me I'm not going mad? I understand we should be looking at small, iterative changes, but these have got to be scoped out, and this should be done, as far as I understand, during Sprint Refinement. Currently we have zero time devoted to this process.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff