Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am employed in a very brilliant company with a true intention of doing XP. Communication is good and management is open to constructive discussion but due to pressing time constraints, some certain things are considered too RUP to be discussed.

At the moment I'm a little troubled with the volume of change that becomes necessary while implementing the stories. I believe many of these discoveries (which take time and effort of course) are the responsibilities of the story writers (customers, end users and product owners) and not the developers. To put is short, user-stories are too conceptual and just convey the underlying intention but lack enough details (specially pre-conditions and post-conditions, relevance to other stories, dependencies and alike). The developer is expected to fill in the blanks at his own discretion by the virtue of XP developers being designers and analysts at the same time. The problem is many of these blanks are discovered after some wrong assumptions have made made their way into evaluation time and code since noticing added complexities emerge than initially anticipated. Even then finding the right thing to fill in takes time which is - to various degrees - considered as deviation from the initial estimations.

I'm looking for a constructive way of conveying these implications to the management in a way that would not pose me as someone who is trying to unnecessarily complicate things. I'm new and as yet I have not established much credibility.

You insights are most welcome.

Closely related and somehow gives an answer : How much detail about a user story can a developer expect?

share|improve this question
4  
well I'm no XP expert, but if the team is doing assumptions then they are doing XP wrong. –  Songo Apr 7 '13 at 9:49
4  
If the team is making wrong assumptions which could be avoided just by asking more questions to the end-users, then there goes something very wrong inpedepently of the methodology. –  Doc Brown Apr 7 '13 at 9:58
    
ned to fill in the blanks but those assumptions & risks, need to go back to the business guys/ customers with a date by when you expect answers so you can keep the project on track. –  tgkprog Apr 8 '13 at 12:15
4  
Welcome to the real world of software development. ANY software development methodology works if the entire process is followed, everyone is engaged and developers have adequate skill. The problem is that seldom do all of those occur. Which makes me laugh at all the people who say you are doing XP wrong. If everything were always ideal then not only do you not need XP you probably don't need any methodology. The strength of a process is in how well does it work when not followed to a T. If XP breaks because of deviations then there's a problem with XP not those trying to practice it. –  Dunk Apr 8 '13 at 13:33
2  
As for not getting detailed enough user stories from the customer. That's expected. On most probjects I work on there are usually at least 2 levels of stories. The high level (which the system requirements are derived from) and more detailed stories that the developers need, created by the developers. Those detailed stories help discover the missing requirements that the high level stories missed. And there's usually a lot. You can then provide specific questions back to the customer. In the meantime you take your best guess and go with it and hope the customer responds in a timely manner. –  Dunk Apr 8 '13 at 13:39

10 Answers 10

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development.

You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when they don't really know what they want, the same thing will happen.

It's a large part of a developer's job to figure out what the customer wants, when they often don't really know.

First, ask questions. Where the answers you get seem unsatisfactory, create a prototype. Show the customer what they're asking for, and let them tell you how it's not what they really want. Start with a paper prototype, then move onto an HTML-based one, with no code behind it. Then do the smallest amount of development you need to produce a nearly-working product and show them that. Leave the tricky bits as late in the process as you possibly can.

This might sound time-consuming in itself but, when compared to redeveloping a supposedly-finished product, it isn't.

Also, keep the stories as small as possible. Invariably, what the business wants is an epic, something that can be broken down into many deliverables. This is better because you won't have developed too much when they look at the final release candidate and scream "Oh no, that's really not what we were looking for."

share|improve this answer
    
Can't upvote this answer right now (limit reached), but this is the best one of the lot. In addition, after you iterate once or twice, most customers will like you for it. –  KK. Apr 7 '13 at 18:35
    
Along these same lines. If there are lots of blanks the User Story is probably too high level to be useful anyway and should screen to be broken up into smaller, more easily defineable, stories. –  Seth M. Jun 13 '13 at 15:42

Even then finding the right thing to fill in takes time which is - to various degrees - considered as deviation from the initial estimations.

That does not sound very "XP"ish to me.

I am in no way an XP expert, but AFAIK the XP idea is to adapt your specs and your estimation continuously whenever you got feedback from the process. And the process is "analyse a little - design a little - code a little - test a little - and then get user feedback to correct your wrong assumptions as early as possible. You can also try to get user feedback even more early, for example, after designing some parts of your software (like the UI), on a sheet of paper or a whiteboard and discuss that with a user or customer. I don't think the "XP way" forbids such an approach just because of having "user stories".

Here is a nice article about how to get feedback more early by using specs. I think this kind of thinking is "methodology"-independent, and the arguments presented there will help you with your debate with management.

share|improve this answer

To summarize you are in the following situation:

  1. You are new.
  2. The project (I assume your are talking about a running project) has pressing time constraints.
  3. The developer is expected to fill in the blanks at his own discretion.
  4. The company you are working in is intending to practice XP. However user stories seem not to be applied in a way which fits into the XP methodology. On the other hand "The developer is expected to fill in the blanks at his own discretion".

Think about point 4: My opinion is that agile practices should be adapted to the needs and the culture of a company/team (not the other way around). Identify where the company sticks to the XP methodology and where it deviates. This is the groundwork for a constructive approach to your concerns.

Due to 1 and 2 you are currently not in a good position to question if the company applies XP in a reasonable way. Starting a discussion with the management will very likely pose you as someone who "complicates things". However you can start to discuss your concerns with your fellow developers. Maybe you will find some developers who think the way you do. Maybe there is a senior developer who will then convey your concerns to the management. But do not expect that things will change fast, especially not in the current project. However the project will give you a good opportunity to gather more data which adds more substance to a constructive approach.

Now to point 3: I think that good user stories are collaboratively written by customers/end users/product owners and developers. Show some initiative: Look for some opportunity to directly ask the authors of the user stories. If this is not possible ask some senior developer or the management how to deal with open questions which must be answered by the authors of the user stories. Maybe you can at least have some written correspondence. Since you need to fill out the blanks on your own discretion, then your choice should be to actively involve the customers/end users/product owners.

At some point you have made enough thoughts and observeration about how your company applies XP (or agile practices in general). Maybe some time has already passed and you are not perceived as a greenhorn anymore. Maybe your active involvement with the customer has shown some positive effects. Maybe the next project is already starting. Maybe your also have already some backup from other develeopers. Maybe you find out that the way it works is not bad at all. The point is that then you will then have enough ideas to convey your concerns to the management, based on real experience and data within your company.

share|improve this answer
    
+1 for bringing back the focus on the "someone who complicates things" part. –  ashy_32bit Apr 8 '13 at 9:31
    
@ashy_32bit: Not to be picky but, if that's where you wanted the focus of answers, you should have made that the focus of the question. (ie. removed most of the second paragraph) –  pdr Apr 8 '13 at 10:54

Frankly, user stories should not have a whole lot of detail. "I want the software to do X, to meet Y business need" should be sufficient. After all, you not want business people dictating how to do that - you're the expert at the software and best practices therein.

That said, the developers also need to ask: "how do you expect this to work?", "what happens when that interacts with feature Z?". Developers don't make requirements, they make implementation.

It also sounds as though there is too much of a gap between implementation and evaluation. Stakeholders should be looking at prototypes, at half-done code every few days. That lets you get feedback before getting too far into the weeds.

share|improve this answer

If you are asked to estimate a story that seems incomplete to you, make it known that you have questions about the story and that you can't give a proper estimation before those questions are answered.

Then, ask your questions and make sure the answers become part of the story.

If you are forced to give an estimation even when your questions are not (all) answered, you can choose to either refuse to give an estimation or to clearly indicate that you are assuming the worst possible outcomes for the remaining blanks in your estimation (which probably will make your estimation a high outlier).

share|improve this answer

What you do is not an agile way of development. Instead, you are working with low quality requirements. It is false that an agile way of development is not to specify requirements.

Instead, they need to initially specify as much as possible, and if needed change later. Then you split your work into parts and implement in iterations. After each iteration, you have something finished.

Difference to waterfall development, is in waterfall development, everything is implemented with initial requirements, and changed at the end.

share|improve this answer

It sounds like the developers are completely removed from the creation of the user stories. Do you expect just to be able to read them like a detailed spec and build it right the first time? If you could do that, you wouldn't need XP or any other agile methodology.

Someone should be asking questions if the story is too vague. Where does Acceptance Testing occur?

User stories are meant to change. You need to deal with it.

share|improve this answer

Though a developer could write a story/ detailed requirements i have not seen many who are good at it. we are good at pointing out issues, suggesting better flows but as an input to already well written case.

Have worked on new and existing products and with both had cases where the requirements where just 5- lines and we were expected to fill the blanks and make an 'understanding' or more elaborate document.

Projects moved much better then we had our own professional services person who helped with this (or in one case a VP who jumped in as there was no one else available). Either way its a waste of time to develop (unless no feedback is coming back and the deadline has not changed). so my suggestion : ask for more details, provide more, ask for time bound feedback to your assumptions and documentation and state that its a risk that there will be rework and delays if you do not get this information by x date.

share|improve this answer

Regardless of the development methodology, if whatever you are using to define requirements makes the developer make assumptions, it needs to be kicked back to the business side. I often have a good idea of what answer I would prefer so I kick things back like this:

XYZ is unclear to me. Does it mean ABC? Or am I missing something? (Assume XYZ is the requirement, assume ABC is the assumption I would like to make as a developer)

It takes far less time to get things cleared up before you make bad assumptions than to redo. Developers who make guesses about requirements without getting confirmation that their guess is right tend to be bad developers and they cost their company a lot of money. If a bad manager won't let you kick things back, then explain to him how much more expensive in terms of time and money it is to do it wrong. If he still insists, then do what he says and when it fails UAT, the next time you want to kick something back, remind him of how costly it was the time he wouldn't let you. If he still won't listen, find a better boss.

The other value of kicking things back is that, gradually, the business will learn what you need and give you better requirements.

share|improve this answer

As a developer,

I need to fully understand the specifics of a user story,

so that I can confidently estimate and implement it.

On other words, you must ask questions until you understand the specifics of the story. This is done in iteration planning and acts as decision point: if you cannot estimate it, you cannot build it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.