Friday, December 26, 2014
Thursday, November 27, 2014
- Architecture and design trade-offs, other decision making, and issue resolutions happen in a timely manner and architecture sub-systems are mature enough,
- Release planning is effective, and
- Prioritization of backlog is based on business needs as well as dependencies.
- Build architecture and design components or sub-systems and mature them iteratively as early as you can. Avoid procrastination. In the name of ‘Agile’ do not let all aspects of your technical components (or sub-systems) emerge all the time until you complete the final iteration.
- Validate if user stories can include all related NFRs in your project. In some projects this may not be possible. In that case, you will have to plan for technical stories to address NFRs at regular intervals to suit your release plan.
- At iteration level, focus on INVEST. At release level or product roadmap level, focus on everything else discussed in this blog series. If your project is large, consider disciplined or structured parallel agile development teams working at multiple levels such as features, design/architecture, independent verification etc.
- Focus on proactive grooming and creating INVEST stories for upcoming iterations. If user stories are volatile inside iterations, find ways to improve grooming sessions. With multiple parallel small teams moving forward in sustainable pace, you will need the right number of teams working on identifying and creating user stories for upcoming iterations.
- Identify complex requirements and come up with techniques to deal with them. Complex requirements will need extra grooming expertise and efforts as compared to other requirements. Resolve dependency issues of complex requirements. Follow techniques such as TDD, ATDD, or BDD and ensure high level of collaboration with business at the time of development, testing and acceptance.
Thursday, November 20, 2014
Thursday, November 13, 2014
Sunday, November 9, 2014
- Do your homework - let the creators of requirements (e.g. Business analysts) think through, specify requirements and put them for review before communicating it to a broad set of audience.
- Create test scenarios with test data - complex scenarios need illustrations of multiple paths with test data.
- Conduct walk-through - walk-through enables collaboration and improves understanding.
- Facilitate Q&A sessions.
- Involve the creator (Business analyst or business user) in test case /test data reviews and testing.
In one of my projects, there was a constant issue reported by team members. It was about complex and changing requirements. When we analyzed the situation we found that only 20% of the requirements were very complex or highly complex. 80% of the requirements were not so complex – they were either simple or medium in terms of complexity – obviously, we had our own approach or mechanism to decide complexity of requirements.
‘So, what is the real issue here? Is it about managing complex requirements?’ I enquired my team members.
‘About 20% of our requirements are complex but in general requirements are not stable. We see changes every other day.’
‘So, is this about ongoing changes to requirements?’
‘There is more to it. We are not very clear about some of the requirements. So, we ask questions to understand different scenarios. In this process, requirements evolve.’
‘Some of the business users or product owners are very busy. They are not available to answer our questions. We have to do several follow-ups. That makes things complex.’
‘Oh. Ok. Our issues are because of several factors – complexity of requirements, requirement stability, clarity of different scenarios, and availability of business users or subject matter experts. Is that right?’
‘Yes. That is right.’
That was a learning moment that helped me understand that managing complex requirements is not about complex requirements alone! That is about the complexity of managing requirements because of factors such as complexity, stability, clarity, availability and so on.
Wednesday, October 1, 2014
- Facilitate walk-through sessions.
- Encourage collaboration and resolve queries in a timely manner.
- Validate understanding. For example, let the readers present it to subject matter experts.
- The quantity and quality of questions asked by readers
- Level of participation or collaboration in walk-through sessions
- Quality of document handed off and user feedback
- Quality of the outcome (for example, the next level of work products such as test cases or source code).
Believe it or not, most software projects cannot do without documentation and many of them require significant documentation handoff from initial days. Beware! Documentation handoff can and will become a trap in your project. You need to be cautious!
Tuesday, July 29, 2014
Related Posts: Tips on Embracing Agility in BI Projects
Friday, June 20, 2014
Data Extraction in Small Chunks