Category Archives: Requirements
I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:
I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:
Always ask yourself, “what’s the what?”
Always ask yourself, “why?”
As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.
The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.
The team was under pressure to deliver a rewrite of the flagship product after having been handed an agressive delivery date. In spite of the Scrum board and other information radiators in their area, the Scrum Master had to deliver progress reports to the CEO every day. The company president and vice presidents attended sprint reviews and grilled the team whenever a story was not closed or sprint goal not met.
One could easily argue that a fixed scope and fixed delivery date is in no way agile – end of discussion – but this still happens in organizations that use (at least partially) agile practices leaving Scrum Masters to navigate choppy waters.
Of course the team developed some coping mechanisms, the most insidious of which was kicking the can down the road.
Whenever the team encountered unexpected complexity or scenarios when working on a story, they said “this wasn’t in the story that we planned, so let’s call the current story done so that our sprint metrics will look good and handle the extra stuff sometime later.” Everyone except for the Scrum Master was happy – for awhile. Team velocities looked good. Stories were being closed as planned. On the surface it looked like features were being completed. The teams were going to deliver on schedule. The Scrum Master knew deep down that they were either going to deliver late or deliver an application with enormous amounts of technical debt. She also knew that the organization could not handle to truth so she soldiered on.
Then the bubble burst. The collective “oh crap” moment happened when people realized that the system should be production-ready but was not. Some features were incomplete. Bugs were still there from parallel testing that had been performed months ago. There was no room in the time before the expected completion date to resolve all of the open issues. Market launch would be delayed.
The ‘shadow backlog’ existed in the developers’ minds and in the list of open defects that were logged elsewhere from ongoing user testing. There were no product backlog items for them and no sprints in the release plan for addressing them.
– Make sure that all remaining work is visible. Create backlog items for stories, technical debt, and bugs. The backlog consists of Product Backlog Items (PBIs), not just user stories.
– Get user feedback during the sprint to avoid surprises later. Ideally users are integrated into the process via acceptance test driven development (ATDD). At a minimum they have an opportunity to see stories in action and provide feedback in the sprint. Any feedback and new ideas that cannot be incorporated during the sprint should be captured as real backlog items and sized/prioritized.
– Don’t be afraid to keep a story open if it was more difficult or took longer than expected when sprint planning was originally done. Better to take a little heat now rather than have the bubble burst later.
– Avoid ‘bucket stories’ near the end of a release that become a dumping ground for stuff that did not get completed in the sprints. Bucket stories can quickly grow exponentially and delay the release.
The team was eager to launch into their first release planning exercise. Wisely, the Scrum Master and Product Owner (PO) did not hand the team a list of already-written user stories. They knew that while it would take the team a little more time to identify and write the basics of each story, it would pay off many times over with the understanding and ownership of the stories created by this exercise.
The PO presented the first requirement. “Team, we need to provide the back office system with a summary of the day’s sales.”
A developer on the team eagerly grabbed a sticky note and jotted down the story.
While the developer’s willingness to jump in and start writing a story is exactly what the PO or Scrum Master like to see, what is wrong here? What should the PO and Scrum Master do in response to this story?
Part of the Product Owner’s job is to make sure the team understands WHO the feature is for, WHAT it is for and WHY it is needed. This is crucial because it allows the team to understand the vision for the feature, who it will benefit, and the value that it provides. This information can spur questions from the team and provide guidance as they weigh various potential solutions. Technical teams can very quickly jump to the HOW without fully understand WHAT they are building or WHY they are building it.
We all know the template for a user story: “As a <type of user> I want <some goal> so that <some reason>”.
Right away we can see that the story does not address who the story is for. As written, the story provides at best a modest sense of the goal, but with verbiage such as “Add task in scheduler to invoke C# application” it is more about the solution that the business goal.
Lastly, one of the most powerful components of a user story is the “so that” clause. This forces the PO to justify the story’s existence. What benefit will it provide? How will it help achieve the overall vision? If the PO can’t come up with a “so that” clause, there is a good chance that the story is not needed or is not well-enough understood.
Recognizing this, the Scrum Master jumps in and explains this to the Product Owner and the team members. The PO gives a more thorough explanation of the story, focusing on how it will help the business. The end result:
It may not be perfect yet, but it provides much more meaningful information than the original version. This story will trigger valuable questions from and conversation with the team and ultimately lead to a better product.
- If the story title is about the technical HOW and not the business WHAT, guide the team in rewriting it so that it reflects the business need or goal and not the technical solution.
- Don’t overlook the “so that” part of the story. It forces the PO and team to justify the story and truly understand it.
One of the most challenging aspects of adopting agile is requirements gathering and definition. The challenge is not because agile has complex methods for describing requirements, rather quite the opposite. Agile methods such as writing a user story on an index card and then relying on conversations between developers, product owners, and users to carry the story through construction might work for simple systems but breaks down when the domain or requirements are complex.
Product owners typically take center stage in driving requirements definition. These product owners, many of whom come from business units (rather than IT), cobble together various methods for capturing and communicating requirements. This is done without the benefit of understanding the difference between structured, object-oriented, test scenario-based, or other industry-standard requirements methodologies and why those methodologies came to exist. At scale, user stories on index card approaches break down, leaving team members and businesses as collateral damage. Please do not misinterpret this as Product Owner bashing – developers are just as susceptible to thinking that they can handle complex problems without the benefit of structure.
Enter the Business Analyst. When a team is responsible for solving a large, complex problem, the business analyst works with the users, product owners and developers to root out key information. For applications through which there are significant data flows, this could mean creating (gasp!) data flow diagrams. For a highly-interactive, event-based system, this could be use case models or sequence diagrams. A good Business Analyst possesses a skill set that many developers and product owners lack: the ability to understand the complexity of requirements and the best way to capture them.
One trap to avoid is to have the Business Analyst become the conduit (a.k.a. bottleneck) through which all communication between the users and developers occurs. This collaboration continues to be important and valuable, and the Business Analyst is involved to ensure important details are surfaced and consistent with the overall application.
- A formal Business Analyst skillset is probably not necessary for simple applications.
- For complex applications, the Business Analyst plays a key role in ensuring that the right software is built.