4 ms·

This is not a question of agile or not. This is software estimation and design. To be able to decompose a feature, you need to learn how to build the software

This is not a question of agile or not. This is software estimation and design. To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Consider a large billing page, for example. Step 1 is to look at the front end. What components do I need to build? (React might use components, or a set of partials and templates in rails, for example.) So, then, I know I need X subtasks, where I will build the pieces I need to expose that behavior to the client to start. I then look down into the backend. That might be a simple task on the backend, or given 20 minutes of looking, I might see problems that I'll need to tackle. The problems are their own subtasks. I may be able to group some of the front end to a single back end ticket, or I might need a separate subtask for each. Now, I'm likely to miss something. However, that's why this is an estimate rather than a concrete task list. It's to get started so that we know, at minimum, what it's going to take. It's not necessarily simple, but it is a skill that can be developed.

wvenable 7y ago
> To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Even easier than building the software in your head is actually building the software. I often don't know what the shape of the problem is until I've built something. The users often don't know what they want until they've seen something. The failure of Agile as implemented is that it's still all about extensive meetings and planning. Software is not like building a bridge where you write out the blueprints and the expensive part is then building the bridge. Software is the blueprint. To be truly agile is to be able to get software features and changes running and out to users as quickly as possible. You can never get all the information -- if users could provide the details absolutely necessary to build the software on day one then they'd be the programmers. Being experienced helps you naturally scope problems but you'll still be wrong from time time. Being able to iterate on users feedback and dealing with your own failed assumptions is the key.
- seangrogg 7y ago
  > I often don't know what the shape of the problem is until I've built something. This is the majority of estimation failures as far as I've seen. You can only "estimate" so far and then leave significant padding for all the other minutia that will likely creep in.
  - BigJono 7y ago
    This is why I like to estimate on a more macro level. Define features loosely, with a few lines of text about what they are and how they relate directly to a business goal (how will it make money, make the product better etc), then as a dev, you should be aligning the work to that (which is a piece of cake because they're still flexible). You should still have more granular planning, but it should serve the purpose of aiding the dev in completing the feature. You decide to do more granular planning when, as a dev, you look at a feature and go "The implementation is still ambiguous or I still have questions about how it relates to business goals". Basically, invert the communication channels and shift responsibility to the devs. They have some loose business goals to hit, and the other staff provide support when they need it. This solves so many problems I run into in enterprise dev. It kills Parkinson's Law (since the team members that are in the bottleneck are now responsible for the bulk of work generation within the team), it also gets rid of a whole class of poor decisions that are made without the proper context (since now you have a closer relationship between business goals and development).
- constantine42 7y ago
  Yes and no. Testing is a very important part of agile, yet if you don't have a somewhat final internal design, you will find yourself changing your unit tests every time you refactor your code. As a rule of thumb, changing your unit tests is a no-no. First off, it means your code is brittle. Second is that you can't trust tests that must change every time your code changes. Might as well not even have them. Unit tests are supposed to tell you if your refactoring is still working. For the most part, you should only refactor implementation details, not the "API". There is also a design to uncertainty trade off. The less you know about something, the less time you should spend designing because you can't design something you don't understand. But the more your understand something, the more time you should probably spend designing. Knowing how much design is too much is subjective and personal. I forget where I read it, XP(Extreme Programming) or Code Complete, but someone worth listening said, to paraphrase, "I've never regretted spending more time on design before I started coding". And I'm pretty sure it was part of XP that said the main purpose of XP(Agile) is to deal with the unknown. The more you know, the less Agile and the more waterfall you should be, saying that for some projects, a 6 month sprint is perfectly valid. I am in an interesting situation where I am both the programmer and the domain expert. Generally customers come to our team describing a problem that other companies can't figure out. We're pretty much allowed to design everything how we feel like because we're the best at it. We can do virtually any project in a single go of it without feedback from the customer, but we still do agile because it helps with scheduling, planning, prioritization, etc. We're a "value add" team, which makes things really interesting. None of our work is sold, but the work is important to land large contracts for the companies core services.

wvenable 7y ago

> To be able to decompose a feature, you need to learn how to build the software in your head before you go to paper. Even easier than building the software in your head is actually building the software. I often don't know what the shape of the problem is until I've built something. The users often don't know what they want until they've seen something. The failure of Agile as implemented is that it's still all about extensive meetings and planning. Software is not like building a bridge where you write out the blueprints and the expensive part is then building the bridge. Software is the blueprint. To be truly agile is to be able to get software features and changes running and out to users as quickly as possible. You can never get all the information -- if users could provide the details absolutely necessary to build the software on day one then they'd be the programmers. Being experienced helps you naturally scope problems but you'll still be wrong from time time. Being able to iterate on users feedback and dealing with your own failed assumptions is the key.

seangrogg 7y ago
> I often don't know what the shape of the problem is until I've built something. This is the majority of estimation failures as far as I've seen. You can only "estimate" so far and then leave significant padding for all the other minutia that will likely creep in.
- BigJono 7y ago
  This is why I like to estimate on a more macro level. Define features loosely, with a few lines of text about what they are and how they relate directly to a business goal (how will it make money, make the product better etc), then as a dev, you should be aligning the work to that (which is a piece of cake because they're still flexible). You should still have more granular planning, but it should serve the purpose of aiding the dev in completing the feature. You decide to do more granular planning when, as a dev, you look at a feature and go "The implementation is still ambiguous or I still have questions about how it relates to business goals". Basically, invert the communication channels and shift responsibility to the devs. They have some loose business goals to hit, and the other staff provide support when they need it. This solves so many problems I run into in enterprise dev. It kills Parkinson's Law (since the team members that are in the bottleneck are now responsible for the bulk of work generation within the team), it also gets rid of a whole class of poor decisions that are made without the proper context (since now you have a closer relationship between business goals and development).
constantine42 7y ago
Yes and no. Testing is a very important part of agile, yet if you don't have a somewhat final internal design, you will find yourself changing your unit tests every time you refactor your code. As a rule of thumb, changing your unit tests is a no-no. First off, it means your code is brittle. Second is that you can't trust tests that must change every time your code changes. Might as well not even have them. Unit tests are supposed to tell you if your refactoring is still working. For the most part, you should only refactor implementation details, not the "API". There is also a design to uncertainty trade off. The less you know about something, the less time you should spend designing because you can't design something you don't understand. But the more your understand something, the more time you should probably spend designing. Knowing how much design is too much is subjective and personal. I forget where I read it, XP(Extreme Programming) or Code Complete, but someone worth listening said, to paraphrase, "I've never regretted spending more time on design before I started coding". And I'm pretty sure it was part of XP that said the main purpose of XP(Agile) is to deal with the unknown. The more you know, the less Agile and the more waterfall you should be, saying that for some projects, a 6 month sprint is perfectly valid. I am in an interesting situation where I am both the programmer and the domain expert. Generally customers come to our team describing a problem that other companies can't figure out. We're pretty much allowed to design everything how we feel like because we're the best at it. We can do virtually any project in a single go of it without feedback from the customer, but we still do agile because it helps with scheduling, planning, prioritization, etc. We're a "value add" team, which makes things really interesting. None of our work is sold, but the work is important to land large contracts for the companies core services.