• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

requirements planning

Ratio of Developers to Analysts in Agile

Conventional wisdom generally holds that the ratio of developers to analysts in an Agile framework is about 4:1 or 3:1. In essence, it says that 1 analyst can support the work of 3 or 4 full time developers working on a project. For Waterfall projects, this ratio is higher and …

Read More

Gathering Requirements in a Green Field

In my time at Seilevel, I’ve had a chance to work with a number of different clients, operating in a range of industries. Oftentimes, these clients begin projects with a number of legacy systems that need updated or integrated with; it is a rare opportunity for a project team to …

Read More

The Most Important Part of A User Story

The last couple of years has seen a wholesale shift in development methodologies among the Fortune 1000 companies from Waterfall to Agile.  It is not an exaggeration to say that the Agile revolution that has been brewing in small companies, startups and web companies for the last decade and a …

Read More

Setting boundaries in Agile Requirements Management

I was once part of a team at a consumer-facing technology company, who described themselves as incredibly fast-paced, operating within a rapidly changing environment. This team was smaller (4 developers in a 10-person business unit), so I expected the ability to get things done quickly to be one of our strengths. Upon joining, …

Read More

Aligning User Expectations with Business Objectives

Projects with clearly defined business objectives can and do fail even if they deliver functionality that syncs closely with the business objectives defined for the project, but do not meet user expectations. This may seem counter intuitive at first blush since the primary purpose of any enterprise software development effort …

Read More

Software Requirements Impact on Technical Debt – Part 2

This is the second part of a two part series on the impact of software requirements on technical debt. Part 1 defined technical debt, delved into its importance, discussed its symptoms and summarized some strategies for paying it down. Part 2 discusses the specific impact that software requirements can have …

Read More

How to Shoot Yourself in the Foot: Conclusion

Conclusion to the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Short-change Time Spent on Software Requirements or Don’t do Them at All Don’t Listen to Your Customer’s Needs Don’t use …

Read More