• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to make sure the requirements and requirement changes are not missed during Agile Sprint

 
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I work in a team at offshore which works with onsite team and follow 10 day sprints. During the first day of the sprint the architect from onsite gives the requirements in Power point PPT diagrams. During the sprint also some requirements changes. Since, I am the senior most in the offshore development team, I share this with rest of team and we all work on these requirements. It has been seen that at the end of 10 day sprint when we give a demo , some of the requirements have been missed or wrongly implemented.

The reasons for this are :

1. On first day of the sprint during our evening (end of the day) on skype meeting, we are shown and shared with at PowerPoint presentation slide has diagram of what we are supposed to implement in the remaining sprint. After seeing the diagram some doubts/clarifications come to mind, I ask immediately which he speaks and I note down quickly. I need to try to minimise any errors in noting down the clarification correctly.


2. The diagram shown on the first day is good but bit abstract so there would be a lot of design implementation doubts which get cleared in coming days.

3. Some of the doubts/clarification do not immediately come to the mind during the meeting on first day of the sprint and come to mind at a later stage. I send email to ask these questions of the next day.

This causes 2 problems :

1) Once the reply comes, it may be 3rd or 4th day of the sprint and we are left with lesser days to implement.
2) There may be error in my understanding of the requirement implementation  which architect from onsite intends to give us and what I understand as we have to implement.


What can be a way to make sure that the requirements are not missed and we end up implementing exactly as the architect wants us to implement?

Thank You.



 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem is primarily is a lack of communication and feedback. You should be inspecting and adapting the work in progress more often. You can codify your understanding in the form of test cases. You can demo work in progress more often. Also, the architect giving you requirements is a process smell. This suggests to me that your "stories" are more technical in nature rather than business-focused.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Thank You.

You should be inspecting and adapting the work in progress more often. You can codify your understanding in the form of test cases.




This looks like a good way. I started creating user acceptance test cases and sending it in email to architect and manager.


You can demo work in progress more often.



We have sprint demo on the last day of sprint (10th day). I can try for a demo in between in that case.


Also, the architect giving you requirements is a process smell. This suggests to me that your "stories" are more technical in nature rather than business-focused.



How is this a process smell? What better way can it be done in ?


 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why is an architect giving you requirements? It's your users who should be talking to you about what your program should be doing.

Architects are there to guide and coach developers so that the code they write stays consistent with the overall system vision and design. Architects are there to make sure that the technical solution is effective and supports the creation of functionality required to meet users' needs.

If developers are only getting requirements from the architect, the danger of missing requirements is greater because the architect becomes a single point of failure. If the architect misunderstands or misses something then everything else that gets done downstream from the architect will be wrong.

Satyaprakash Joshii wrote:I started creating user acceptance test cases and sending it in email to architect and manager.


This sets off many alarm bells for me. Why are you not co-creating the user acceptance tests with the users? Why are you submitting those to the architect and manager instead? This makes me think you are doing "faux Agile," which is "Agile" in name only but you are really doing command-and-control traditional waterfall development.

 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We are working on a product and they will find a customer for it.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:We are working on a product and they will find a customer for it.


That sounds like an 8-alarm fire to me.

A manager and architect have very different concerns. I seriously doubt their ability to act effectively as proxies for customers. Even when you have a dedicated product owner, the chances of building the right product without actual customers to give you feedback become slim to none, in my opinion. I speak from first-hand experience in Fortune 100 companies.

Has there been at least a market study done on which to base requirements for this product? If you can't say yes to this, that's another alarm.

How long have you been developing this product? If more than three months, yet another alarm bell.
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Powerpoint is not, in my opinion, a good agile tool. It takes a certain amount of work to put together Powerpoint slides and agile really needs something that doesn't distract as much from the primary efforts. I'd recommend something like a kanban board.

But aside from that, take Junilu's advice very seriously. I learned a long time ago that the managers (both customer and my own) only "know" what the users need. The users often know better.

And one of the virtues of Agile is that I also learned that once you give a product to a user, they find that it changes what they need, which means that goals may need to be shifted and features added/removed/changed. Which, in Agile is supposed to be relatively easy (as opposed to finding them all at once after much useless work was done under waterfall).
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I totally missed the reference to PowerPoint requirements docs.

Wow. That is a two-alarm fire in and of itself.
 
Rancher
Posts: 4801
50
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My interpretation (for what it's worth) is that the OP is working for an offshore company who is doing some of the dev work for whoever this other company is.

I doubt they'll know anything about market studies etc.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think there's a pretty good chance you're right there, Dave. Seems like there's no shortage of companies willing to throw their money down the same pit despite many others already coming away empty-handed.
 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If they (the offshore company) get paid by the hiring company I doubt they'll care all that much.


Of course, that might be a big 'if'?
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Has there been at least a market study done on which to base requirements for this product? If you can't say yes to this, that's another alarm.



I do not know whether it was done or not. Even if it was done, I would not be aware of it.

How long have you been developing this product? If more than three months, yet another alarm bell.



1 month. What is the reason that it would have been alarm bell had it been more than 3 months?


 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My interpretation (for what it's worth) is that the OP is working for an offshore company who is doing some of the dev work for whoever this other company is.



We work from offshore with the onsite team(same company). We have been told to create Product and our sales team will try search customer for it. To the customer , they will show the Product we are developing and show that we already have this and based on your needs we can build for you.  
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If they (the offshore company) get paid by the hiring company



I have written in the above post on how we work. I am not sure what 'hiring company' means here.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Three months of working the way you described is a long time in terms of an Agile software development lifecycle. That is a HUGE smell in my opinion. You say you've only worked on it for a month. How many releases have you done? I don't mean production release either. I'm talking about any release to some environment that your sales people can access so they can start playing around with the software and give the development team some feedback.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Re "hiring company," I think Dave was making a reasonable (although apparently mistaken) assumption about the relationship between your onshore and offshore teams.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Without the ability to interact with actual users of the software or a reasonably empathetic representative, the only link the development team has to the purpose and utility of what you are producing is what the architect and manager give you. That is low fidelity at best in my opinion and at worst is going to be off the mark by quite a bit. Writing software without a good understanding of how it will truly benefit its users is problematic and wasteful at best.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's possible (but I think improbable) that your company is operating in lean startup mode and trying to run quick and dirty experiments to test the market. If that's the case, I'd still expect someone other than an architect and manager to be giving the team guidance on what the software needs to do.  A manager is there to ensure the proper resources and environment are provided for the development team to be effective. The architect is there to make sure the development team is effectively using resources to come up with the best possible solution to the problem. He's there to guide the team and ensure the software is built right. It is the user or product owner's responsibility to ensure that the right thing is built.
 
Dave Tolls
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:
I have written in the above post on how we work. I am not sure what 'hiring company' means here.



Ah, as Junilu says I made an assumption about the relationship that was incorrect.
Thanks for clearing that up.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The problem is primarily is a lack of communication and feedback. You should be inspecting and adapting the work in progress more often. You can codify your understanding in the form of test cases. You can demo work in progress more often. Also, the architect giving you requirements is a process smell. This suggests to me that your "stories" are more technical in nature rather than business-focused.



I tried to codify requirements in form of test cases during this Sprint and felt better and more in control of the work I was doing. I will adopt this practice forever in future. I created those and sent to architect on email (which I will check-in somewhere in future).  I wrote that please review and let us know in case of any changes so that we can do that during the sprint before the sprint demo. He did not reply anything (he is busy too but that is expected for everyone). During demo there was one comment from him which said I want you to work faster instead of spending time on test cases which testing team will do (but that would be in future ). I told him that we need test cases to make sure we are following the requirement. He said but that you should do from our diagram itself instead of wasting time. After saying again he finally said Yes but did not like it seems for some reason as he wants fast work. I agree that we need fast work but then they are also pointing to us missing the requirements . So not creating test cases and also not missing requirements both cannot happen together.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have nothing nice to say about the architect, his attitude, or his intelligence. I'll just leave it at that and let you draw your own conclusions about what I think.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:he is busy too but that is expected for everyone



Well, it takes a lot of time to update project specs when you do it with PowerPoint.
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:I agree that we need fast work but then they are also pointing to us missing the requirements . So not creating test cases and also not missing requirements both cannot happen together.



"You can have the code fast or you can have it right. Choose one."

It's too bad that people who haven't figured that out yet are put into management positions.
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cheap, quickly, correct. Guess which one most people choose?

Then they gripe about the poor quality of the system and why is sensitive data being flogged for sale by hackers from Pakistan/Albania/wherever?

Because software is simple!. My 10-year old cousin Billy wrote a program just the other day. All You Have To Do Is... And "IT Doesn't Matter" (THANK YOU, Wall Street Journal!)

                     

Oh, and lest we forget, rushing to market is no guarantee for success. The Apple Newton failed miserably. The Palm Pilot learned from their mistakes. It came out later, but was a lot more profitable.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:During demo there was one comment from him which said I want you to work faster instead of spending time on test cases which testing team will do (but that would be in future )..


I'd argue that it takes longer to write code without test cases. Because then you have to check it manually. And you have to keep checking it manually as you add more code. This is a tremendous waste of time.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I have nothing nice to say about the architect, his attitude, or his intelligence. I'll just leave it at that and let you draw your own conclusions about what I think.



Yes I understand. I felt more in control when I worked with test cases. However I think , instead of user acceptance test cases , may be I can focus on Unit test cases during my development.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'd argue that it takes longer to write code without test cases. Because then you have to check it manually. And you have to keep checking it manually as you add more code. This is a tremendous waste of time.



Does that mean you recommend to write code without test cases?  Which way do you suggest?
 
Tim Holloway
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Satyaprakash Joshii wrote:

I'd argue that it takes longer to write code without test cases. Because then you have to check it manually. And you have to keep checking it manually as you add more code. This is a tremendous waste of time.



Does that mean you recommend to write code without test cases?  Which way do you suggest?



SJ, read that quote again.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry. By mistake, I had misunderstood it to other way round.
 
Satyaprakash Joshii
Ranch Hand
Posts: 440
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

You can codify your understanding in the form of test cases.



Is documenting the Acceptance Criteria under the user stories another way for this. Is it correct that when there is acceptance criteria under user stories , it is a good way to make sure that requirements would not be missed?
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic