Improving Collecting Requirements in Scrum

Estimating

Karrie Dash Sykesville, Md, United States

I manage a software development team and we follow the scrum methodology. One area of improvement that I want to focus the company on is our scope management processes, particularly the collect requirements activity.

After finishing development on a new website, the customer wanted to add a new feature, an admin portal. So the entire process went something like this:
1. Gather high-level requirements from customer
2. Meet with customers to gather more detail requirements about each high-level req.
3. Create User Stories with known acceptance criteria and add more information
4. Meet with customer to review acceptance criteria and make changes

5. Meet with the development team to discuss the acceptance criteria & generate questions for the customer and provide feedback (ie: potential solution ideas)
6. Meet with customer to review questions & feedback that were generated by the development team
7. Meet with the development team to review answers provided by the customer & verify there are no other questions from the development team
8. Finalize the acceptance criteria

9. Conduct official release planning & sprint planning

This phase went really well from start to end; both the developers & the customers were happy, and there were minimal regression bugs that needed to be fixed. There were more planning meetings than usual, but the team was happy with the process and asked for me to do the same with a new project.

There were some changes made during the sprints but it didn't have a negative effect on the project. The development team knew what the vision was, what they would need to do from start to end, and how each requirement affected another, so we were able to resolve issues before starting actual work.

I think this process went well for two reasons:
1) The work to be done was simple; adding a small feature to an already developed project
2) Since we developed the original website, the team already knew how the system worked, what changes could be made, how to make it, and how long it might take.

If I had to make any changes to the process that was followed for the new admin feature, I would have conducted steps #5-7 with both the customer & development team in one meeting, as I think it would have saved time for myself and the development team. But, there were issues with the customer and their project manager, so to manage the relationship and communication, it was best to keep the developers & customer PM separated. Organizational changes were made on the customer side so we now work with a different PM, who I would have felt comfortable doing steps 5-7 with everyone together.

Here is my dilemma/question:
I'm not quite sure how to implement a similar process for a completely new project, especially a website that was built by other developers. How do other PMs handle this process? What is your step by step process?

Since we don't fully know how the website was built or their coding styling, we find it difficult to answer questions regarding exactly how to develop a new feature or how long it will take. There are a lot of known-unknowns that we won't have answers to until development has started. I've had the team conduct technical discovery before we start release planning, but I'm not sure if that is enough to answer how to make a change or how long it will take with confidence. This then makes it difficult to create a project plan with dates since I'm sure some of the estimated times will be less than the actual time needed.

If we are adding new features to an already-developed website, I think it is important to also know how the current website works, so we can accurately test for regression bugs and make sure that our new features work well with the current features. If we don't know how the current features are integrated together, I would image we may break the integrated features due to lack of knowledge.

Posted: Apr 10, 2019 11:26 AM

Sort By:

Joshua Render Product Owner| Cognizant Harrisville, Ny, United States

Well, first things first, your developers should get a copy of the code to review. They should look it over to try and understand it. That isn't always possible, the customer may not want to do it until work begins. That would be a risk.

Getting someone from the customer who knows the code, a SME, or a user of the application might also help understand what you are dealing with. If you can get diagrams of the database and try to understand that, it could help as well so they know what values are stored and maybe how to get at them.

Failing the ability to get time to go through the code ahead of time, you may have to think like you have to build it from scratch - because you just might have to in some cases. For the most part, repeat what you did. Good call on combining steps 5-7, have the team work with the customer as much as necessary to gain the needed understanding. If you can do that, then do that, especially on someone else's code.

Don't get stuck on the small things. Focusing too much on the details is almost guaranteeing you will waste time. Some items may be deemed not worth it if the team learns that huge parts of the code just won't work with what the customer wants to do and the customer may have to weigh time and costs in order to carry out those tasks.

Posted: Apr 10, 2019 3:10 PM (Updated by author: Apr 10, 2019 3:11 PM)

Karrie Dash Sykesville, Md, United States

Thanks!

How much time would be reasonable to plan for code review? Or a better question may be, how does a PM determine how much time is needed? Is this one of those, try and see what happens situation since each project is different? I like to think that 2 weeks is typically a good amount of time for a small or medium project.

Have you had customers provide a copy of the code during the RPF process? My new customer gave us a user account to their website during the RFP process so we could see the user's workflow.

I'm also wondering how any tech company can provide estimated dates and accurate pricing during the RPF process if we don't have information regarding the current code & setup.

...

1 reply by Evgeny Trushin

May 17, 2019 4:11 AM

Evgeny Trushin

...

How much time would be reasonable to plan for code review?
From my experience, the code review process might take a lot of time (15%+ of the development time). In order to keep it under control (5-10%) the proper code review protocol needs to be established. This protocol has to have at least coding guidelines.

Posted: Apr 11, 2019 10:51 AM

Evgeny Trushin Cronulla, Nsw, Australia

Apr 11, 2019 10:51 AM

Replying to Karrie Dash

...

Posted: May 17, 2019 4:11 AM

Please login or join to reply

Improving Collecting Requirements in Scrum

Sponsors

Vendor Events

Guessing is not a strategy: How to build decision velocity with AI and real-time data

Newsletters