10 ms·

Split user stories ruthlessly and get value earlier

98 points by mikeborozdin 9y ago

Spooky23 9y ago
It's easy to spot when agile webdev types don't do this... you end up with a responsive mobile site that is missing half the features that you want. It's easy for sharpie commandos to sort interactions by priority and build a user story that hits most of the priority interactions. Splitting isn't natural especially when the designers aren't very experienced. IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.
- ethbro 9y ago
  > IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured. Critical in my experience. I usually call this the "smart ass SME" (subject matter expert). Or, "Go out on the floor and find me someone who does the work every day, has been doing so for a decent amount of time, and who still complains when things are broken and has no problem speaking up." I can tease out issues from a generic complaint. I can't from silence. The other thing you'll find they're useful for is throwing out ass-backward use cases that seem logical to management (and me) but are stupidly inappropriate for some obvious reason to an actual person doing the workm
- octalmage 9y ago
  For us this is the product owner. They are the ones that do the user studies to backup feature requests with data. It's important to test assumptions about what users want. This way we don't end up building stuff because someone random thought they wanted it.
Zigurd 9y ago
This is all correct, and following this advice will improve your project planning. BUT it skirts the problem that Agile makes people think they can plan a project without knowing what's a functional spec, what's an implementation plan, and what of those things is implied by a user's desires. You can't arrive at a really good plan just writing more-concise stories that don't span too many hidden requirements. It helps, but it isn't a substitute for domain knowledge and systems analysis training.
- UK-AL 9y ago
  The hard part for agile projects is that you only loosely know what is the desired end result. Specs should and will change.
  - Zigurd 9y ago
    That's the good part about agile. The bad part is that the idea of a "story" goes a bit too far in trying to make specification creation accessible. Decomposing stories into smaller pieces is a solution that's palatable to many because it avoids the hard work: Gaining more domain knowledge, and developing critical thinking.
maaaats 9y ago
Where I work now they have attached too much overhead per story. Time tracking, statuses in jira, separate confluence page with stringent rules about the content etc. So we now make huge stories in order to actually get to spend some time implementing stuff.
- bunderbunder 9y ago
  I think this is where most organized agile implements tend to fail. There's a lot of jumping straight to the user stories and sprints and all that, and skipping over some of the more basic agile ideas, first. One of them is that any artifacts that aren't executable code and test cases is likely to be dead weight that is expensive but delivers almost no business value. A good agile book will (IMO) even go so far as to straight out say that if you're in a situation where you can't avoid having that level of documentation and paperwork, whether it be due to contractual obligations or organizational culture, then most agile methodologies are probably going to intensify your overhead problems rather than reduce them.
- talldan 9y ago
  I imagine when something about the project changes, it takes a really long time to rewrite all those stories? Or you end up never re-assessing because it takes too long.
  - maaaats 9y ago
    We often end up reusing the stories for completely different stuff, as they then have already been approved so we can skip some of the boilerplate, haha.
gtramont 9y ago
Reminded me of Paul Hammant's posts: - https://paulhammant.com/2012/04/24/call-to-arms-average-story-sizes-of-one-day/ https://paulhammant.com/2012/04/24/call-to-arms-average-stor... - https://paulhammant.com/2012/11/12/smaller-stories/ https://paulhammant.com/2012/11/12/smaller-stories/
- gtramont 9y ago
  And Mike Cohn's SPIDR tips for splitting stories: - https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large
perlgeek 9y ago
Following a chain of links and a google search, I landed at this podcast episode which I really liked: http://talkingcode.com/podcast/episode-14-jeff-patton/ http://talkingcode.com/podcast/episode-14-jeff-patton/ It's an interview with Jeff Patton, who seems to be a pretty well-known name when it come to user stories and story mapping, and I really enjoyed his take on this matter.
maxxxxx 9y ago
With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car. But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right. With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.
- lotsofpulp 9y ago
  I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).
  - maxxxxx 9y ago
    I think they had checklist like this: Retro design, quirky, different. I actually like the concept. But the implementation is just terrible.
    - Infernal 9y ago
      I think the number one item on the checklist was "how can we build a car that /just barely/ crosses the line into 'light truck' category so has much lower fuel mileage targets per CAFE standards". On that point they did very well.
  - nebabyte 9y ago
    > But the end result was a crappy car. A lot of features were implemented in a subpar way.
- forinti 9y ago
  It worries me that I'll paint myself into a corner with Agile one day. Plus, the design documentation gets pulverized into lots of tiny user stories, so it's hard to get new people on board.
bonoetmalo 9y ago
Grooooaaaaaaannnnn. The amount of developer hours that go into micromanaging user stories and story points is infuriating
- IshKebab 9y ago
  I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number." Blarghf. Why not just "Implement about dialog with version number.". I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.
  - Domenic_S 9y ago
    A user story is not a complete spec. The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't. The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?
  - cormacrelf 9y ago
    There is some merit in at least trying to think about your users at every stage of the design. Methodically putting the user in every sentence refocuses your work on what makes the experience better for them. You are right that making it super repetitive makes you filter out the bits about user interaction when you read a long list. User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss. Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.
  - another-dave 9y ago
dlhavema 9y ago
Has anyone had good success with enterprise level projects managed in jira? Background: each story has deliverable value to the stakeholder/ Ask: Download file from vendor, process file with error and success counts, save results in X datastore, email report with stats to specified DL...
- zo1 9y ago
  Jira is just a ticketing system with a lot of fancy (and optional) features built on-top of it. Or are you asking specifically about the Jira Agile feature?
hal9000xp 9y ago
If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras. Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it. Agile/scrum is biggest cargo cult I've ever seen in my life.
- sixdimensional 9y ago
  Actually, my opinion is that "agile" the way I most often see it is nothing more than a lighter weight variation of what we were already doing with SDLC. Time/cycles are compressed, documentation is not quite as structured, but the basic ideas are similar. I agree the hype cycle distorts things too much. I think maybe your opinion is a bit too harsh, but - I would think to use whatever technique succeeds for the need and the team, whether more or less formal. So more power to you if the technique you prefer works.
- acdjuiamadfn 9y ago
  I cannot "upvote" you enough.
  - deleted 9y ago
    [deleted]
- sixdimensional 9y ago
  Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method. I'd be curious what software engineering process you'd prefer then, for your own company? Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of quality due to standardization of process and method.
acdjuiamadfn 9y ago
Okay, I read the article but why is this thing called "user story"?
- sixdimensional 9y ago
  A user story is basically a feature. It is higher level than a use case. Read Alistair Cockburn http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories http://alistair.cockburn.us/Stop+confusing+use+cases+and+use....
SoulMan 9y ago
I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I think it helps middle management (top management only see some high level slides) get some numbers to measure how much work has been done and how much time is remaining to complete the features in the road map (epic progress). On the flip side everyone else forced to make those numbers good (either by working on weekend or taking short-cut with tech debts or in worst case compromise quality). This becomes obvious when managers set rules like - 90% of the stories must be completed at the end of two weeks sprint (if there are less than 10 stories, you have to close all of them). I see all stories coming to code review , merged, deployed , tested & closed on the last day of the sprint. Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing) scrum master end up make it happen as his job is to make sure "sprint commitments" are met. Now enter the world of SAFe. You plan for 3 to 5 months and can't do anything different in this time period (Where is the agility ?). You can't prioritize tech debts that you carried when you took shortcuts earlier to deliver MVP as "things are going alright". Hence, no iteration , only look ahead deliver more features. Spend a week on just planning and trying to accommodate feature based on "High level estimate" which is usually 50% accurate because you have not broken down to stories yet or has not done any experiments to check if some technology or recipe works or not. In addition to this you have hours of grooming, standups planning, retro , review in each up coming sprint involving the whole team. I think every time you fit a process which may have worked in auto-mobile industry to software industry trying to "get more value " (lean is a new thing) you cease to be an innovative company.
- UK-AL 9y ago
  Honestly, most agile people don't think safe is agile. It was literally created to try to fit agile methods into company that still thinks in waterfall.
- ju-st 9y ago
  Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.
talldan 9y ago
> You read articles that say it should be possible to complete a user story within a single sprint, ideally within a few days. That’s entirely accurate. I'm surprised by that, as I tend to break down stories even smaller, to the point where they can be completed in a day or two. Anything that takes longer I consider risky and potentially a rogue story that could end up eating a lot of time. Smaller stories are easier to manage, easier to refactor, it's much easier to review the resulting code and they usually have less complexity. I think it's sometimes easier to clear blockers with smaller stories as well. Downsides are that it can be harder to get an overall view on the progress being made during a sprint, and sometimes tasks can have more dependencies or it can be harder to work on things in parallel. It also takes more time to prioritise the backlog.
tootie 9y ago
I generally advocate this approach, but there is a limit. Each new story is a context switch for everyone involved. It's easy for a product manager to lose track of the holistic POV if they are tracking too many stories. The dev has to stop and start or worse yet, split very tightly coupled work among more than one dev.
adrianratnapala 9y ago
I approve of this, but I come at it from an I-just-want-to-be-an-engineer point of view. When looking for velocity, the first thing to optimise is the feature list. Too often the idea of doing something useful quick and dirty devolves into writing bad code that looks like it covers a feature set until you scratch the surface and find the whole thing is made of bugs. But if you reduce the feature set (that's the first kind of dirty) then you can build a system that really does what it says on the tin. And the second kind of dirty (code), deosn't matter so much, because in a smaller system the total technical debt is less.
andrewprock 9y ago
"As a developer, I want to be able to log time spent on projects. So that the company could analyse [sic] time spent on different projects." This user story is utterly absurd. In this case, the "user" is actually the company, not the developer. The developer usually wants to provide business value by adding new features, or fixing bugs. And this is a feature, but it's not a feature for the developer. It's a feature for the company. The fact that it got broken down into manual data entry features like: "Users (read developers) select a project and enter hours spent for each day" Makes me question whether the users were involved in making the stories at all. This article feels like an illustration of what is wrong with Big-A Agile, not an exemplar of how to do it right.
asdfpoiu10 9y ago
Looks like someones been drinking too much of the agile kool-aid...

98 points by mikeborozdin 9y ago

It's easy to spot when agile webdev types don't do this... you end up with a responsive mobile site that is missing half the features that you want. It's easy for sharpie commandos to sort interactions by priority and build a user story that hits most of the priority interactions. Splitting isn't natural especially when the designers aren't very experienced. IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.

ethbro 9y ago
> IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured. Critical in my experience. I usually call this the "smart ass SME" (subject matter expert). Or, "Go out on the floor and find me someone who does the work every day, has been doing so for a decent amount of time, and who still complains when things are broken and has no problem speaking up." I can tease out issues from a generic complaint. I can't from silence. The other thing you'll find they're useful for is throwing out ass-backward use cases that seem logical to management (and me) but are stupidly inappropriate for some obvious reason to an actual person doing the workm
octalmage 9y ago
For us this is the product owner. They are the ones that do the user studies to backup feature requests with data. It's important to test assumptions about what users want. This way we don't end up building stuff because someone random thought they wanted it.

Zigurd 9y ago

This is all correct, and following this advice will improve your project planning. BUT it skirts the problem that Agile makes people think they can plan a project without knowing what's a functional spec, what's an implementation plan, and what of those things is implied by a user's desires. You can't arrive at a really good plan just writing more-concise stories that don't span too many hidden requirements. It helps, but it isn't a substitute for domain knowledge and systems analysis training.

UK-AL 9y ago
The hard part for agile projects is that you only loosely know what is the desired end result. Specs should and will change.
- Zigurd 9y ago
  That's the good part about agile. The bad part is that the idea of a "story" goes a bit too far in trying to make specification creation accessible. Decomposing stories into smaller pieces is a solution that's palatable to many because it avoids the hard work: Gaining more domain knowledge, and developing critical thinking.

maaaats 9y ago

Where I work now they have attached too much overhead per story. Time tracking, statuses in jira, separate confluence page with stringent rules about the content etc. So we now make huge stories in order to actually get to spend some time implementing stuff.

bunderbunder 9y ago
I think this is where most organized agile implements tend to fail. There's a lot of jumping straight to the user stories and sprints and all that, and skipping over some of the more basic agile ideas, first. One of them is that any artifacts that aren't executable code and test cases is likely to be dead weight that is expensive but delivers almost no business value. A good agile book will (IMO) even go so far as to straight out say that if you're in a situation where you can't avoid having that level of documentation and paperwork, whether it be due to contractual obligations or organizational culture, then most agile methodologies are probably going to intensify your overhead problems rather than reduce them.
talldan 9y ago
I imagine when something about the project changes, it takes a really long time to rewrite all those stories? Or you end up never re-assessing because it takes too long.
- maaaats 9y ago
  We often end up reusing the stories for completely different stuff, as they then have already been approved so we can skip some of the boilerplate, haha.

gtramont 9y ago

Reminded me of Paul Hammant's posts: - https://paulhammant.com/2012/04/24/call-to-arms-average-story-sizes-of-one-day/ https://paulhammant.com/2012/04/24/call-to-arms-average-stor... - https://paulhammant.com/2012/11/12/smaller-stories/ https://paulhammant.com/2012/11/12/smaller-stories/

gtramont 9y ago
And Mike Cohn's SPIDR tips for splitting stories: - https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large

perlgeek 9y ago

Following a chain of links and a google search, I landed at this podcast episode which I really liked: http://talkingcode.com/podcast/episode-14-jeff-patton/ http://talkingcode.com/podcast/episode-14-jeff-patton/ It's an interview with Jeff Patton, who seems to be a pretty well-known name when it come to user stories and story mapping, and I really enjoyed his take on this matter.

maxxxxx 9y ago

With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car. But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right. With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.

lotsofpulp 9y ago
I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).
- maxxxxx 9y ago
  I think they had checklist like this: Retro design, quirky, different. I actually like the concept. But the implementation is just terrible.
  - Infernal 9y ago
    I think the number one item on the checklist was "how can we build a car that /just barely/ crosses the line into 'light truck' category so has much lower fuel mileage targets per CAFE standards". On that point they did very well.
- nebabyte 9y ago
  > But the end result was a crappy car. A lot of features were implemented in a subpar way.
forinti 9y ago
It worries me that I'll paint myself into a corner with Agile one day. Plus, the design documentation gets pulverized into lots of tiny user stories, so it's hard to get new people on board.

bonoetmalo 9y ago

Grooooaaaaaaannnnn. The amount of developer hours that go into micromanaging user stories and story points is infuriating

IshKebab 9y ago
I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number." Blarghf. Why not just "Implement about dialog with version number.". I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.
- Domenic_S 9y ago
  A user story is not a complete spec. The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't. The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?
- cormacrelf 9y ago
  There is some merit in at least trying to think about your users at every stage of the design. Methodically putting the user in every sentence refocuses your work on what makes the experience better for them. You are right that making it super repetitive makes you filter out the bits about user interaction when you read a long list. User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss. Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.
- another-dave 9y ago

dlhavema 9y ago

Has anyone had good success with enterprise level projects managed in jira? Background: each story has deliverable value to the stakeholder/ Ask: Download file from vendor, process file with error and success counts, save results in X datastore, email report with stats to specified DL...

zo1 9y ago
Jira is just a ticketing system with a lot of fancy (and optional) features built on-top of it. Or are you asking specifically about the Jira Agile feature?

hal9000xp 9y ago

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras. Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it. Agile/scrum is biggest cargo cult I've ever seen in my life.

sixdimensional 9y ago
Actually, my opinion is that "agile" the way I most often see it is nothing more than a lighter weight variation of what we were already doing with SDLC. Time/cycles are compressed, documentation is not quite as structured, but the basic ideas are similar. I agree the hype cycle distorts things too much. I think maybe your opinion is a bit too harsh, but - I would think to use whatever technique succeeds for the need and the team, whether more or less formal. So more power to you if the technique you prefer works.
acdjuiamadfn 9y ago
I cannot "upvote" you enough.
- deleted 9y ago
  [deleted]
sixdimensional 9y ago
Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method. I'd be curious what software engineering process you'd prefer then, for your own company? Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of quality due to standardization of process and method.

acdjuiamadfn 9y ago

Okay, I read the article but why is this thing called "user story"?

sixdimensional 9y ago
A user story is basically a feature. It is higher level than a use case. Read Alistair Cockburn http://alistair.cockburn.us/Stop+confusing+use+cases+and+user+stories http://alistair.cockburn.us/Stop+confusing+use+cases+and+use....

SoulMan 9y ago

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I think it helps middle management (top management only see some high level slides) get some numbers to measure how much work has been done and how much time is remaining to complete the features in the road map (epic progress). On the flip side everyone else forced to make those numbers good (either by working on weekend or taking short-cut with tech debts or in worst case compromise quality). This becomes obvious when managers set rules like - 90% of the stories must be completed at the end of two weeks sprint (if there are less than 10 stories, you have to close all of them). I see all stories coming to code review , merged, deployed , tested & closed on the last day of the sprint. Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing) scrum master end up make it happen as his job is to make sure "sprint commitments" are met. Now enter the world of SAFe. You plan for 3 to 5 months and can't do anything different in this time period (Where is the agility ?). You can't prioritize tech debts that you carried when you took shortcuts earlier to deliver MVP as "things are going alright". Hence, no iteration , only look ahead deliver more features. Spend a week on just planning and trying to accommodate feature based on "High level estimate" which is usually 50% accurate because you have not broken down to stories yet or has not done any experiments to check if some technology or recipe works or not. In addition to this you have hours of grooming, standups planning, retro , review in each up coming sprint involving the whole team. I think every time you fit a process which may have worked in auto-mobile industry to software industry trying to "get more value " (lean is a new thing) you cease to be an innovative company.

UK-AL 9y ago
Honestly, most agile people don't think safe is agile. It was literally created to try to fit agile methods into company that still thinks in waterfall.
ju-st 9y ago
Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.

talldan 9y ago

> You read articles that say it should be possible to complete a user story within a single sprint, ideally within a few days. That’s entirely accurate. I'm surprised by that, as I tend to break down stories even smaller, to the point where they can be completed in a day or two. Anything that takes longer I consider risky and potentially a rogue story that could end up eating a lot of time. Smaller stories are easier to manage, easier to refactor, it's much easier to review the resulting code and they usually have less complexity. I think it's sometimes easier to clear blockers with smaller stories as well. Downsides are that it can be harder to get an overall view on the progress being made during a sprint, and sometimes tasks can have more dependencies or it can be harder to work on things in parallel. It also takes more time to prioritise the backlog.

tootie 9y ago

I generally advocate this approach, but there is a limit. Each new story is a context switch for everyone involved. It's easy for a product manager to lose track of the holistic POV if they are tracking too many stories. The dev has to stop and start or worse yet, split very tightly coupled work among more than one dev.

adrianratnapala 9y ago

I approve of this, but I come at it from an I-just-want-to-be-an-engineer point of view. When looking for velocity, the first thing to optimise is the feature list. Too often the idea of doing something useful quick and dirty devolves into writing bad code that looks like it covers a feature set until you scratch the surface and find the whole thing is made of bugs. But if you reduce the feature set (that's the first kind of dirty) then you can build a system that really does what it says on the tin. And the second kind of dirty (code), deosn't matter so much, because in a smaller system the total technical debt is less.

andrewprock 9y ago

"As a developer, I want to be able to log time spent on projects. So that the company could analyse [sic] time spent on different projects." This user story is utterly absurd. In this case, the "user" is actually the company, not the developer. The developer usually wants to provide business value by adding new features, or fixing bugs. And this is a feature, but it's not a feature for the developer. It's a feature for the company. The fact that it got broken down into manual data entry features like: "Users (read developers) select a project and enter hours spent for each day" Makes me question whether the users were involved in making the stories at all. This article feels like an illustration of what is wrong with Big-A Agile, not an exemplar of how to do it right.

asdfpoiu10 9y ago

Looks like someones been drinking too much of the agile kool-aid...