This week's book giveaway is in the Beginning Java forum.
We're giving away four copies of Get Programming with Java (MEAP only) and have Peggy Fisher on-line!
See this thread for details.
Win a copy of Get Programming with Java (MEAP only) this week in the Beginning Java forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
Bartenders:
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

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

 
Ranch Hand
Posts: 253
2
  • Mark post as helpful
  • send pies
  • 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: 12825
211
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • 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: 253
2
  • Mark post as helpful
  • send pies
  • 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: 12825
211
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • 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.

 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!